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Critical  to  the  success  of  all  future  battlefield  commanders  is  the  rapid  retrieval  of 
relevant,  time  sensitive  information.  Some  of  this  information  will  be  available  locally 
while  the  remainder  is  stored  in  the  United  States.  DARPA's  Battlefield  Awareness  and 
Data  Dissemination  (BADD)  program  attempts  to  deliver  heterogeneous  data  to  the 
battlefield  using  Asynchronous  Transfer  Mode  (ATM)  protocol.  ATM  was  originally 
designed  to  implement  dynamic  virtual  channels  over  duplex,  high-speed,  high  capacity 
fiber  optic  cabling.  The  problem  addressed  was  to  determine  which  algorithm  best 
schedules  calls  on  BADD's  ATM  network  that  uses  static  virtual  channels  over  simplex, 
error  prone,  long  delay,  satellite  links.  Because  the  BADD  project  uses  ATM  in  such  an 
unusual  way,  and  because  of  the  need  to  determine  a  schedule  for  transmissions  over  the 
heterogeneous  static  channels,  we  modeled  BADD  using  the  state-of-the-art  network 
simulation  tool,  Optimized  Network  Engineering  Tools  (OPNET).  We  determined 
several  modifications  that  must  be  made  to  existing  network  simulators  to  allow  them  to 
model  next-generation  networks.  Our  simulation  shows  that  a  greedy  algorithm  yields  a 
53%  decrease  in  the  overall  completion  time  and  a  46%  increase  in  average  bit  throughput 
over  FIFO  scheduling. 
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I.         INTRODUCTION 
A.      BACKGROUND 

From  several  years  before  Operation  Urgent  Fury,  the  invasion  in  Grenada  in 
1983,  until  after  Operation  Just  Cause,  the  invasion  in  Panama  in  1989,  the  Depart- 
ment of  Defense  (DoD)  fielded  numerous  new  stand-alone  automated  systems.  These 
systems  provided  solutions  to  narrowly  focused  problems  and  were  not  interoperable 
with  other  DoD  systems.  The  story  of  the  enterprising  young  Army  officer  in  Grenada, 
calling  his  home  base  in  North  Carolina  to  coordinate  naval  gunfire  support,  because 
his  equipment  could  not  directly  communicate  with  naval  equipment,  illustrates  the 
problems  encountered  by  DoD  personnel  in  using  such  systems.  Today  these  systems 
are  referred  to  as  "vertical"  because  they  do  not  facilitate  "horizontal"  communica- 
tion. (They  are  also  sometimes  referred  to  as  "stove-pipe.")  From  multiple  experiences 
such  as  the  one  described  in  Grenada,  the  DoD  has  learned  that  this  vertical  design 
paradigm  leads  to  massive  duplication  of  subcomponents  and  incompatibility  between 
systems.  Such  a  paradigm  also  interferes  with,  rather  than  facilitates,  joint  military 
operations.  In  light  of  the  current  downsizing  in  military  force  structures,  coupled  with 
the  dwindling  military  research  and  development  funds,  the  DoD  must  develop  and 
field  systems  that  are  integrated  both  vertically  and  horizontally.  All  new  automated 
systems  must  share  their  information  across  a  wide  spectrum  of  military  applications 
that  support  interoperability  requirements.  These  modified  design  environments  are 
also  essential  for  the  required  reduction  in  procurement  costs. 

The  Department  of  Defense  has  made  some  progress  in  recent  years  towards 
adapting  and  embracing  civilian  research,  development,  and  procurement  practices. 
It  now  seeks  to  learn,  adopt  or  adapt,  as  necessary,  these  corporate  practices  to  meet 
unique  military  requirements,  such  as  providing  highly  mobile  communications  and 
automated  support  in  sparse  communication  environments.  For  example,  utilizing  a 
commercial  mobile  phone  system  as  the  baseline  for  development  of  a  mobile  military 


communication  platform  makes  sense;  however,  the  military  must  often  add  redund- 
ancy to  its  networks.  This  redundancy  is  needed  to  permit  communication  to  continue 
even  when  some  communication  lines  are  lost  in  battle.  Other  examples  of  consider- 
ations that  military  planners  must  address,  but  their  commercial  counterparts  need 
not,  include  noisy  Radio  Frequency  (RF)  links,  extreme  bandwidth  constraints,  and 
security  concerns. 

Recent  and  ongoing  developments  in  the  area  of  information  availability  and 
accessibility  within  large,  widely  distributed,  commercial  corporations  have  direct 
applications  within  military  applications.  With  high  mobility  and  global-reach  re- 
quirements, the  military  must  develop  and  field  automated  systems  that  integrate  all 
available  and  accessible  information.  The  exploration  and  possible  use  of  emerging 
technologies,  such  as  Asynchronous  Transfer  Mode  (ATM)  [Ref.  1],  for  high- 
speed data  communications  are  essential  to  the  success  of  future  military  systems. 

In  one  such  effort,  personnel  at  the  Naval  Command  Control  and  Ocean  Sur- 
veillance Center,  Research,  Development,  Training,  and  Evaluation  Division  (NRaD), 
under  the  direction  of  Dr.  Clifford  J.  Warner,  are  examining  the  use  of  ATM  to  sat- 
isfy the  requirements  for  the  transmission  of  multimedia  data  over  the  Navy's  Joint 
Maritime  Communication  System  [Ref.  2].  They  are  focusing  on  three  areas: 

•  Actively  participating  in  the  Internet  Engineering  Task  Force's  efforts  to  stand- 
ardize an  approach  to  reliable  multicast. 

•  Integrating  Internet  Protocol  (IP)  Quality  of  Service  (QoS)  guarantees  with 
ATM  QoS  to  ensure  QoS  support  through  multiple  layers  of  the  network,  in- 
cluding the  subnetwork  level. 

•  Actively  testing  ATM  equipment  in  their  labs  to  identify  the  ability  of  ATM 
switches  to: 

1.  support  multimedia  applications, 

2.  support  IP  and  ATM  QoS  guarantees, 

3.  interoperate  with  different  ATM  switches, 

4.  support  efficient  multicast  protocols,  and 


5.  integrate  with  legacy  systems. 

These  extensive  efforts  demonstrate  a  recognition  by  the  military  science  and 
technology  experts  that  ATM  is  a  technology  that  might  be  exploitable  in  future 
Command  and  Control,  Communication,  Computer  and  Intelligence  (C4I)  systems. 
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Figure  1.  BADD  Overview  (From  [Ref.  3]). 


Figure  1  displays  the  Battlefield  Awareness  and   Data  Dissemination 

(BADD)  System  [Ref.  3].  The  BADD  system  is  an  ATM-based  communication 
system  that  has  the  primary  goal  of  integrating  all  available  information  to  digit- 
ize the  battlefield  and  to  ensure  that  the  local  battlefield  commander  maintains 
information  dominance  over  opposing  forces.  The  information  needed  to  digitize  the 
battlefield  may  be  available  either  within  the  local  operating  forces  environment  or  may 
be  stored  in  the  vast  electronic  libraries  maintained  by  diverse  organizations  within 
the  continental  United  States.    These  electronic  libraries  include  the  Defense  Intelli- 


gence  Agency  (DIA),  the  Defense  Mapping  Agency  (DMA),  and  Cable  Network  News 
(CNN).  The  BADD  program,  under  the  direction  of  the  Defense  Advanced  Re- 
search and  Project  Agency  (DARPA),  attempts  to  integrate  voice,  data,  video, 
and  imagery  in  this  single  system. 

Fundamental  to  the  success  of  the  BADD  program  is  the  rapid  access  and 
transfer  of  information  to  and  from  the  battlefield.  This  transfer  of  information  must 
include  high-speed  network  connectivity  over  vast  distances.  Likewise,  the  program 
must  include  plans  for  scheduling  retransmission  of  data  that  is  lost  due  to  network 
failures,  which  are  likely  in  the  military  environment.  Additionally,  the  military  does 
not  want  to  lose  any  important  data.  This  requires  the  rescheduling  of  lower  priority 
data  when  it  is  preempted  by  higher  priority  data. 

This  thesis  investigates,  through  simulation,  several  problems  resulting  from 
scaling  of  the  BADD  project  from  its  current  prototype  size  to  its  eventually  en- 
visioned use.  In  particular,  we  use  OPtimized  Network  Engineering  Tools 
(OPNET),  a  commercial  software  product  from  MIL3,  to  simulate  BADD  both  in  its 
current  implementation  and  in  planned  future  implementations  [Ref.  4].  Our  major 
work  concentrates  in  the  areas  of  scheduling  algorithms  for  ATM  virtual  channels  on 
the  BADD  satellite  network  link. 

B.      MOTIVATION 

The  motivation  for  our  research  stems  from  the  need  to  ensure  that  the  Amer- 
ican forces  and  our  allies  remain  the  most  informed  forces  on  the  battlefield.  To 
accomplish  this  goal,  the  warfighter  must  immediately  obtain  all  of  the  most  current, 
relevant  data.  As  the  battlefield  becomes  digitized,  the  amount  of  operational,  in- 
telligence, and  logistical  information  that  may  be  of  interest  to  the  commanders  is 
overloading  the  capacities  of  the  existing  networks.  BADD  examines  new  solutions 
that  will  permit  the  timely  distribution  of  relevant  information  to  even  the  lowest 
echelons. 


Broadcast  is  an  efficient  means  of  getting  information  out  to  a  wide  audience. 
Broadcast  information  has  been  proven  successful  for  the  military  with  the  Navy's  Tac- 
tical Receive  Applications  Network  and  the  Air  Force's  Tactical  Information  Broadcast 
System  Network.  Most  recently,  the  Bosnia  Command  and  Control  Augment- 
ation (BC2A)  Initiative,  supporting  forces  in  the  former  Yugoslavia,  has  proven 
the  usefulness  of  broadcasting  heterogeneous  sets  of  data.  However,  broadcasting  all 
information  to  everyone  will  no  longer  be  an  option  because  there  is  simply  too  much 
information.  Instead,  we  need  to  ensure  that  each  of  the  warfighters  has  the  informa- 
tion that  is  most  relevant  to  them  and  that  the  information  is  as  current  as  possible. 
To  meet  this  need  requires  the  use  of  a  multicast  protocol.  The  BADD  program  plans 
to  use  the  Global  Broadcast  Service  (GBS),  multiple  static  virtual  ATM  chan- 
nels, and  smart  filtering  to  implement  multicast  of  heterogeneous  data  to  satisfy  the 
demands  of  the  forward  deployed  warfighter.  One  problem  that  the  BADD  designers 
have  not  yet  tackled  is  that  of  scheduling  the  data  to  be  broadcast  over  the  multiple 
static  virtual  ATM  channels  in  such  a  way  so  as  to  maximize  the  probability  of  the 
high  priority  data  reaching  the  warfighter.  The  research  for  this  thesis  concentrates  in 
that  area,  borrowing  algorithms  from  SmartNet  [Ref.  5],  a  framework  for  scheduling 
computation  in  a  high  performance,  heterogeneous  computing  network. 

C.      METHODOLOGY 

We  first  construct  an  OPNET  simulation  for  the  BADD  network  using  its 
current  configuration  as  a  baseline  model  for  further  analysis.  Then,  we  will  run  sim- 
ulations using  two  different  scheduling  algorithms  for  scheduling  data  to  be  broadcast 
over  the  static  virtual  ATM  channels.  (The  BADD  architecture  will  hardwire  these 
channels  into  the  satellite  uplink  switch.)  The  first  baseline  simulation  will  run  with 
First-In.  First  Out  (FIFO)  scheduling.  The  second  simulation  will  incorporate  intelli- 
gent scheduling  with  algorithms  used  in  SmartNet,  a  United  States  Navy  developed 
scheduler.  We  will  then  run  multiple  simulations  to  measure  the  maximum  throughput 


of  the  network  with  the  different  schedulers.  Finally,  we  will  perform  analysis  on  our 
results  in  order  to  determine  the  utility  of  intelligent  schedulers  for  these  networks. 

D.      ORGANIZATION 

The  thesis  is  divided  into  seven  chapters.  Chapter  II  reviews  communication 
fundamentals  including  TCP/IP  and  ATM  protocols.  Chapter  III  provides  an  over- 
view of  the  BADD  program  and  the  general  architecture  of  the  network.  Chapter  IV 
elaborates  on  SmartNet's  Intelligent  Scheduling  and  the  past  successes  of  these  al- 
gorithms. Chapters  V  and  VI  provide  background  information  on  the  simulation  soft- 
ware we  are  using  and  elaborates  on  the  design  of  our  simulation.  Chapter  VII  presents 
the  results  of  our  simulation,  provides  the  analysis  of  our  simulation,  makes  recom- 
mendations for  future  work,  and  presents  our  conclusions.  The  appendices  provide 
explanations  of  technical  terms,  computer  code,  scripts  of  simulations,  and  a  list  of 
acronyms  used  throughout  this  document. 


II.         COMMUNICATION  FUNDAMENTALS 

A.  OVERVIEW 

This  chapter  reviews  some  computer  network  basics.  In  particular,  it  con- 
centrates on  basic  computer  communication,  basic  data  characteristics,  basic  Trans- 
mission Control  Protocol(TCP),  User  Datagram  Protocol(UDP),  and  Asyn- 
chronous Transfer  Mode(ATM)  services.  If  the  reader  is  already  familiar  with 
computer  networks,  he  or  she  can  skip  this  chapter. 

B.  BASIC  COMPUTER  COMMUNICATION 

Basic  computer  communication  consists  of  three  distinct  components:  a  source 
(or  sender),  a  destination  (or  receiver),  and  a  path  (or  communication  network) 
between  the  source  and  destination.  Based  on  the  complexity  of  the  computer  commu- 
nication, either  the  source,  destination,  or  the  communication  network  can  add  header 
information  to  ensure  reliability  in  the  communication.  The  International  Standards 
Organization  (ISO)  developed  its  Open  Systems  Interconnection  (OSI)  model  for  com- 
puter communication  (see  Table  I)  to  isolate  various  functionalities  within  different 
layers.  By  grouping  the  communication  functions  into  layers,  communication  services 
at  a  particular  layer  need  only  focus  on  the  needs  of  that  specific  layer,  using  the  ser- 
vices of  the  underlying  layers.  They  need  not  be  concerned  with  the  implementation 
of  the  layers  below. 

C.  DATA  CHARACTERISTICS 

The  three  basic  parameters  that  describe  most  communication  services  are 
time  transparency,  bit  rate,  and  connection  mode  [Ref.  1].  In  the  following 
subsections  we  will  elaborate  on  each  of  these  parameters. 


Layers 

Services 

Layer  7 
Applications 

Provides  access  to  users  and  provides  distributed 
information  services. 

Layer  6 
Presentation 

Provides  independence  to  applications  using  different 
data  representations. 

Layer  5 
Session 

Provides  control  structures  for  communication  between 
different  cooperating  applications. 

Layer  4 
Transport 

Provides  reliable  transfer  of  data  between  endpoints; 
provides  end-to-end  error  recovery  and  flow  control. 

Layer  3 
Network 

Provides  upper  layers  with  independence  from  data 
transmission;  responsible  for  managing  communication 
connections. 

Layer  2 
Data  Link 

Provides  reliable  transfer  of  information  across 
the  physical  link;  responsible  for  synchronization, 
error  control  and  flow  control. 

Layer  1 
Physical 

Transfers  bits  over  a  physical  medium  at  the  level 
of  electrical  signals. 

Table  I.  Open  Systems  Interconnection  (OSI)  Model  for  Computer  Communications 
(Modified  From  [Ref.  6]). 


1.        Time  Transparency 

Time  transparency  refers  to  the  relationship,  in  time,  between  occurrences 
of  events  at  both  the  source  and  the  destination.  Time  transparency  is  formally 
defined  as  the  near  absence  of  time  delay  and  time  jitter  [Ref.  1].  Time  delay 
is  the  difference  between  the  time  the  sender  transmits  the  information  and  the  time 
the  information  arrives  at  the  receiver.  Time  jitter  occurs  when  different  parts  of  a 
transmission  arrive  at  the  receiver  with  different  time  delays.  Network  delay  and  jitter 
are  primarily  the  result  of  two  factors:  propagation  delay  and  processing  delay. 

Propagation  delay  is  the  physical  delay  of  the  medium;  that  is,  the  distance 
(d)  that  the  signal  must  travel  from  the  source  to  the  destination,  divided  by  the 
transmission  speed  of  the  physical  medium.  The  transmission  speed  is  bounded  by 
the  speed  of  light  in  a  vacuum  and  ( j)  in  fiber  optic  cable  where,  c  is  the  speed  of 
light  in  meters  per  second.    For  example,  the  propagation  delay  in  a  one  kilometer 


fiber  optic  cable  is  given  as 

delay  —  2*t3*io&)  ~  0.00001  second. 
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Processing  delay  is  the  sum  of  the  times  required  for  the  network  hardware  and  network 
software  to  process  the  message  at  each  node  within  the  network. 

Some  communication  services  demand  that  the  time  required  to  complete  a 
transmission  be  bounded.  One  example  of  a  such  a  requirement  is  that  time  delay  in 
voice  data  transmission  must  not  exceed  25ms.  When  voice  data  time  delays  exceed 
this  threshold,  the  receiver  will  notice  "choppiness"  in  the  conversation.  Services  that 
require  a  low  bound  on  time  delay  are  called  real-time  services. 

2.       Bit  rate 

There  are  four  basic  classes  of  bit  rate  services;  constant  bit  rate,  variable  bit 
rate,  available  bit  rate,  and  unspecified  bit  rate  [Ref.  7]. 

•  Constant  bit  rate  is  analogous  to  the  bottles  on  a  conveyor  belt  in  a  bottling 
plant.  The  bottles  move  through  the  process  at  a  constant  rate.  Constant 
bit  rate  communication  service  places  bits  on  the  transmission  media  at  a 
constant  rate  and  takes  them  off  the  media  at  the  same  rate.  Again,  using  the 
transmission  of  voice  data  as  an  example,  the  bit  rate  is  constant  at  64kbps 
for  digital  pulse  code  modulated  (PCM)  voice  data.  The  input  voice  signal  is 
sampled  8000  times  per  second  and  each  sample  is  represented  by  8  bits;  each 
8-bit  sample  is  produced  at  this  rate  to  give  a  constant  64kbps  bit  rate. 

•  Variable  bit  rate  is  analogous  to  train  cars  traveling  on  a  railway.  All  cars  are 
on  the  same  track  traveling  at  the  same  speed,  however,  the  train  cars  have 
different  sizes.  Some  cars  are  large  size  carrying  two  levels  of  automobiles,  some 
are  medium  size  carrying  products  in  a  box  car,  and  some  are  small  size  like 
empty  flatcars.  If  we  view  a  railway  tunnel  as  the  size  of  a  communications  link, 
we  can  see  that  at  times  the  tunnel's  area  is  filled  when  large  cars  come  through 
and  is  almost  empty  when  flatcars  come  through.  Video-teleconferencing  is 
an  example  of  a  variable  bit  rate  service.  Using  current  video  compression 
schemes,  a  base  frame  is  sent,  followed  by  a  series  of  smaller  frames  containing 
the  differences  between  the  current  frame  and  the  base  frame    [Ref.  7]. 

•  Available  bit  rate  services  is  the  service  primarily  used  to  support  the  World 
Wide  Web.    Due  to  financial  constraints,  companies  cannot  afford  to  install 


communication  services  that  will  support  their  peak  communication  require- 
ments. They  instead  decide  upon  some  minimum  communication  capacity  that 
must  be  obtained  and  then  live  with  delays  when  peak  data  loads  are  applied. 
Because  the  communication  service  cannot  support  sustained  peak  load,  this 
service  must  support  congestion  control  to  prevent  network  congestion  that 
might  lead  to  network  failure. 

•  Unspecified  bit  rate  has  no  congestion  control  and  does  nothing  to  ensure 
delivery.  With  this  service,  data  is  placed  onto  the  network  and,  with  luck, 
arrives  at  the  destination.  If  congestion  occurs  within  the  network,  data  may 
be  randomly  discarded  without  notifying  the  user.  File  transfer  and  email  are 
possible  users  of  this  type  of  service  because  applications  have  no  constraints 
on  time  of  delivery  and  they  maintain  their  own,  higher  order,  error  control 
mechanisms. 

3.        Connection  mode 

A  particular  service  may  be  connection-oriented  or  connectionless  [Ref. 
7].  In  a  connection-oriented  service,  a  complete  connection  from  sender  to  receiver 
is  established  before  transmitting  any  data.  An  example  of  this  type  of  service  is 
the  original  telephone  circuit  switching  system.  Under  the  telephone  system,  a  user 
picks  up  the  phone  and  dials  a  telephone  number.  The  telephone  system  establishes 
a  dedicated  circuit  between  the  two  users.  This  circuit  is  only  used  by  these  two 
customers  until  one  customer  hangs  up  the  telephone,  thereby  releasing  the  connection. 
One  might  visualize  this  service  as  a  tube,  where  one  user  at  a  time  pours  information 
in  at  one  end  and  the  other  user  takes  the  information  out.  The  information  will 
always  arrive  in  the  same  order  in  which  it  was  sent. 

The  other  common  connection  mode  is  called  connectionless  [Ref.  7].  With  this 
service,  the  user  assigns  a  destination  address  to  each  message  and  places  the  message 
into  the  network.  The  user  has  no  input  and  no  knowledge  about  the  route  the  message 
will  take  to  its  destination  address.  Furthermore,  the  user  has  no  guarantee  that  two 
messages  sent  by  the  same  user  to  the  same  destination  will  arrive  at  that  destination 
in  the  same  order  in  which  they  are  sent.  An  example  of  a  connectionless  service  is 
the  postal  system. 
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D.      COMMUNICATION  SERVICES  AND  PROTOCOLS 

Now  that  we  have  defined  basic  computer  communications  and  data  character- 
istics, we  begin  to  describe  some  common  communication  architectures  which  are  used 
within  the  BADD  system.  As  will  be  depicted  in  Chapter  III,  BADD  is  an  integrated 
system  of  diverse  communication  services;  this  section  will  discuss  each  service  with 
a  focus  on  ATM. 

1.       TCP  Data  Transport  Protocol 

TCP  resides  at  the  transport  layer  (layer  4  in  the  OSI  model),  and  is  designed 
to  work  on  top  of  an  unreliable  network  [Ref.  7].  This  connection-oriented  protocol 
improves  the  reliability  of  communication  by  adding  sequencing,  acknowledgments, 
flow  control,  and  congestion  control  mechanisms.  Due  to  its  complexity,  TCP  often 
becomes  a  major  bottleneck  in  high-speed  communications. 

Figure  2  depicts  the  packet  format  for  a  TCP  packet.  The  standard  data  field 
for  a  TCP  packet  is  1500  bytes  long,  with  a  maximum  length  of  64  kbits. 

The  fields  within  the  TCP  packet  are  as  follows: 

•  Source  Port.  This  is  the  sender's  port  for  its  application. 

•  Destination  Port.  This  is  the  receiver's  port  for  its  application. 

•  Sequence  Number.  This  field  contains  the  sequence  number  of  the  first  data 
byte  in  this  TCP  segment. 

•  Acknowledgment  Number.  Used  for  acknowledgment  messages,  this  fields 
specifies  the  sequence  number  of  the  next  data  byte  TCP  expects  to  receive. 

•  TCP  HL.  TCP  HL  stands  for  TCP  Header  Length  and  specifies  the  total 
number  of  bytes  contained  in  the  header. 

•  URG  Flag.  A  bit  that,  when  set,  tells  the  protocol  to  use  the  value  in  the 
Urgent  Pointer. 

•  ACK  Flag.  A  bit  that,  when  set,  alerts  the  protocol  that  the  acknowledgment 
number  is  valid. 

•  PSH  Flag.  This  bit,  when  set,  activates  the  Push  Function.  The  Push  func- 
tion pushes  this  packet  up  to  the  application  layer  even  if  the  buffer  is  not  yet 
full. 
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24 


32  bits 


Source  Port 


Destination  Port 


Sequence  Number 


Acknowledgement  Number 


TCP 
HL 


Reserved 


Checksum 


Window  Size 


Urgent  Pointer 


Options  (0  or  more  32-bit  words) 


Data  (optional) 


Figure  2.  TCP  Packet  Format  (From    [Ref.  7]). 

•  RST  Flag.  This  bit  is  set  when  either  side  detects  problems  with  the  connec- 
tion and  the  connection  must  be  reset. 

•  SYN  Flag.  A  bit  marking  this  packet  as  a  request  to  establish  a  connection. 

•  FIN  Flag.   This  bit  is  set  when  either  the  sender  or  receiver  finishes  with  a 
connection. 

•  Window  Size.  Used  by  the  sliding  window  flow  control  mechanism. 

•  Checksum.  An  error  detection  code  for  the  header  and  data. 

•  Urgent  Pointer.    A  pointer  to  the  byte  that  immediately  follows  the  urgent 
data. 

2.       UDP  Data  Transport  Protocol 

UDP,  in  contrast  to  TCP,  provides  a  connectionless  service  for  application  level 
procedures  [Ref.  7].  It  also  differs  from  TCP  in  its  complexity  and  support  for  reliable 
communications.  UDP  is  considered  unreliable  because  it  provides  no  mechanisms  for 
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acknowledging  receipt  of  data  and  no  protection  against  duplicate  receptions.  UDP  is 
often  used  when  speed  is  more  important  and  end-to-end  reliability  mechanisms  are 
incorporated  in  the  layer  that  sits  above  the  UDP  layer.  Figure  3  depicts  the  packet 
format  for  the  UDP  packet.  Like  the  TCP  header,  the  maximum  packet  size  for  UDP 
packets  is  approximately  64  kbits. 
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lb 


24 


32  bits 


Source  Port 

Destination  Port 

UDP  Length 

UDP  Checksum 

Data 

Figure  3.  UDP  Packet  Format  (From  [Ref.  7]). 

Each  of  the  fields  within  the  UDP  packet  are  explained  below. 

•  Source  Port.   This  is  the  local  port  for  the  application,  at  the  sender,  using 
the  UDP  transport  protocol. 

•  Destination  Port.  This  is  the  local  port  for  the  application,  at  the  receiver, 
using  the  TCP  transport  protocol. 

•  UDP  Length.  The  length  of  the  UDP  header  plus  the  data  field. 

•  Checksum.  The  error  detection  code  for  the  header  and  data. 

3.       ATM 

a.  ATM  Fundamentals 

Like  TCP,  ATM  is  a  connection-oriented  communication  service.  How- 
ever, ATM  is  lower  in  the  OSI  model  because  ATM  is  also  involved  in  routing  from 
the  source  to  the  destination.  Due  to  its  multi-layer  functionality,  ATM  does  not  "fit" 
cleanly  into  the  OSI  communications  model.  The  conventional  view  is  that  the  ATM 
protocol  is  a  consolidation  of  the  OSI  Network  and  Data  Link  layers. 
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There  are  multiple  sublayers  within  the  ATM  protocol  and  this  section 
will  discuss  several  of  them  in  detail.  Figure  4  shows  the  International  Telecommu- 
nication Union  Telecommunication  Standardization  Sector  (ITU-T)  protocol  reference 
model  for  ATM.  We  provide  this  figure  as  a  conceptual  reference  for  the  reader  when 
we  begin  discussing  the  sublayers  in  detail. 


/^ 

^^                   management  riane 

^^  Control  Plane     ^s^      User  Plane 

Plane  Management           \ 

Layer  Management 

\             \             \ 

Higher  Level  Protocol 

Higher  Level  Protocol 

ATM  Adaptation  Layer 

ATM  Layer 

Physical  Layer 

Figure  4.  ITU-T  ATM  Protocol  Reference  Model  (From    [Ref.  1]). 

The  basic  element  of  the  ATM  layer  is  a  Virtual  Channel  Connec- 
tion (VCC).  When  data  is  passed  to  the  ATM  layer,  a  VCC  is  established  between 
the  source  and  destination.  This  VCC  transports  the  user's  datagrams,  along  with 
control  signals  that  support  the  link  and  manage  the  overall  network.  After  the  user's 
datagram  has  been  transmitted,  the  VCC  is  dismantled  and  its  resources  are  returned. 
This  process  of  connection  and  disconnection  is  extremely  fast  because  much  of  it  is 
incorporated  in  the  ATM  switch  and  network  hardware. 

The  ATM  protocol  includes  a  Virtual  Path  Connection  (VPC) 
which  is  responsible  for  bundling  VCCs  that  have  the  same  endpoint.  To  enhance 
overall  ATM  performance,  all  of  the  VCCs  in  the  same  VPC  are  treated  as  a  single 
entity  within  the  network.  By  reserving  additional  capacity  on  a  VPC,  in  anticipation 
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of  later  VCCs,  new  VCCs  can  be  established  by  simple,  low  overhead,  control  functions 
executed  only  at  the  endpoints.  Figure  5  depicts  the  relationship  between  the  physical 
route  or  cable,  the  virtual  path  (VPC)  and  the  virtual  channel  (VCC). 

Because  ATM  was  primarily  designed  for  use  over  fiber  optic  networks, 
and  such  networks  are  very  reliable,  the  ATM  protocol  provides  no  mechanism  for 
error  control  or  error  correction  [Ref.  1].  These  functions  are  left  to  the  higher  layer 
protocols.  Additionally,  ATM  provides  no  mechanisms  for  acknowledgments;  this 
function  is  also  left  to  the  higher  layer  protocols.  Of  course,  there  are  occasional 
errors  within  fiber  optic  networks,  but  the  probability  is  so  low  that  the  ATM  protocol 
expects  the  higher  layer  to  re-transmit  an  entire  message  if  it  detects  an  error. 


VCC 


Physical  Route 
or  Fiber 


Figure  5.    The  relationship  between  Physical  Route,  Virtual  Path  Connection,  and 
Virtual  Channel  Connection  (Derived  From  [Ref.  6]). 

Unlike  TCP  and  UDP,  ATM  packets  are  all  fixed  length,  and  they  are  re- 
ferred to  as  cells.  Each  ATM  cell  contains  a  48-byte  data  field  (payload)  and  a  5-byte 
header;  it  is  extremely  small  compared  to  the  average  TCP  or  UDP  packet.  The  Inter- 
national Telecommunication  Union  (ITU)  standard  defines  two  different  packet  header 
formats  for  ATM  cells.  One  format,  called  User-Network  Interface  (UNI),  is  required 
at  the  boundary  between  the  user  host  equipment  and  the  ATM  network  (non-ATM 
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to  ATM  equipment  interface).  The  second  format,  called  Network-Network  Interface 
(NNI)  is  used  within  an  ATM  network  (ATM  to  ATM  equipment  interface).  [Ref.  1] 
Figure  6  depicts  the  two  different  ATM  cell  header  formats. 

8  16  24  32  40  bits 


GFC 

VPI 

VCI 

PTI 

C 

L 
P 

HEC 

(a)  UNI 


VPI 

VCI 

PTI 

c 

L 
P 

HEC 

(b)  NNI 

Figure  6.     (a)  ATM  UNI  cell  header  format,     (b)  ATM  NNI  cell  header  format 
(From  [Ref;  7]). 

Each  of  the  fields  within  the  ATM  cell  header  are: 

•  Generic  Flow  Control.  This  field  is  only  present  in  cells  sent  from  a  host 
to  an  ATM  network  and  is  currently  not  used.  In  the  future,  it  could  control 
cell  flow  or  identify  priority  levels. 

•  Virtual  Path  Identifier.  This  field  identifies  the  virtual  path  for  this  cell. 

•  Virtual  Channel  Identifier.  The  VCI  identifies  a  particular  virtual  channel 
within  the  selected  virtual  path. 

•  Payload  Type  Identifier.  ATM  cells  may  carry  user  data  or  ATM  manage- 
ment data.  This  field  identifies  the  type  of  data  contained  within  the  cell. 

•  Cell  Loss  Priority  (CLP).  The  CLP  bit  flag  distinguishes  high  and  low 
priority  data  cells.  A  congested  ATM  network  will  first  attempt  to  drop  cells 
with  CLP  values  of  1  before  dropping  those  with  a  CLP  values  of  0. 

•  Header  Error  Check.  The  error  detection  code  which  is  used  to  detect  errors 
in  the  header  only. 
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When  analyzing  the  properties  of  the  ATM  protocol,  we  define  a  data 
stream  as  a  group  of  cells  that  are  sent  from  one  user  application  to  another.  One 
of  ATM's  strengths  is  its  ability  to  switch  between  data  streams  extremely  efficiently 
because  of  the  small,  fixed  length  of  ATM  cells.  When  a  higher  priority  data  stream 
needs  to  interrupt  a  lower  priority  one,  the  higher  priority  stream  must  only  wait  for 
the  completed  transmission  of  a  relatively  small  data  segment. 

The  most  common  method  for  establishing  priorities  within  an  ATM 
network  is  by  using  a  designator  known  as  the  Class  of  Service.  Using  the  data 
characteristics  previously  defined,  the  ITU-T  recommendation  defines  four  classes 
of  ATM  service:  Class  A,  Class  B,  Class  C  and  Class  D.  Figure  7  illustrates  the 
differences  between  each  of  these  service  classes. 


Class  A 

Class  B 

Class  C 

Class  D 

Timing  between 
source  and 
destination 

Required 

Not  Required 

Bit  Rate 

Constant 

Variable 

Connection  Mode 

Connection  Oriented 

Connectionless 

Figure  7.      The  differences   between  each  of  the  ATM  service  classes   (Modified 
From  [Ref.  1]). 

b.  ATM's  AAL  Layer 

The  AAL  sublayer  sits  just  above  the  ATM  sublayer  and  maps  the  user 
data,  control  data,  and  management  data  into  the  information  field  of  one  or  more 
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ATM  cells.  Because  there  exists  a  vast  difference  between  TCP/UDP  packets  and 
ATM  cells,  the  ATM  protocol  contains  a  specialized  sublayer  to  convert  transport 
protocol  packets  to  ATM  cells.  This  sublayer  is  called  the  ATM  Adaptation  Layer 
(AAL). 

The  AAL  layer  consists  of  several  different  AAL  types  that  are  closely 
aligned  to  the  different  classes  of  ATM  service.  Table  II  defines  each  of  the  AAL 
types.  This  thesis  is  primarily  focused  on  the  AAL  Type  5  service. 


AAL  Type 

Data  Characteristics 

AAL  1 

Constant  Bit  Rate  services 

AAL  2 

Variable  Bit  Rate  services 

AAL  3/4 

Data  which  is  sensitive  to  loss  but  not  to  delay 

AAL  5 

Less  sensitive  to  loss  than  AAL  3/4  but  not  sensitive 
to  delay 

Table  II.  ITU-T  AAL  type  recommendations. 

All  of  the  AAL  layers  are  subdivided  into  two  sub-sublayers:  the  Seg- 
mentation and  Reassembly  (SAR)  Sublayer  and  Convergence  Sublayer  (CS). 
The  CS  layer  is  further  subdivided  into  a  Service  Specific  Convergence  Sublayer 
(SSCS)  and  a  Common  Part  Convergence  Sublayer  (CPCS).  The  relationship 
between  each  of  these  layers  is  depicted  in  Figure  8. 

We  now  address  how  all  of  the  sublayers  within  the  AAL  layer  function 
together  to  convert  a  large  TCP/UDP  packet  into  ATM  cells  for  transport  across  a 
network.  The  SSCS  is  protocol-specific  and  may  include  message  framing  and  error 
correction.  The  CPCS  within  AAL5  begins  by  padding  the  user  data  packet  to  make 
the  entire  message  a  multiple  of  48  bytes.  The  CPCS  then  adds  one  byte  for  the 
User-to-User  field,  one  byte  for  Common  Part  Indicator,  two  bytes  for  the  user  data 
length,  and  four  bytes  for  error  detection.  The  CPCS  Protocol  Data  Unit  is  depicted 
in  Table  III. 
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Network  Layer 


Data  Link  Layer 
(AAL&ATM) 


Physical  Layer 
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ATM 


CS 


SAR 


SSCS 


CPCS 


Figure  8.  The  relationship  between  ATM,  AAL,  SAR,  CS,  CPCS,  and  SSCS  sublayers 
(Derived  From  [Ref.  4]). 


User  Data     Pad     UU     CPI     Length     CRC 


Table  III.  CPCS-PDU  format  for  AAL5 

The  Segmenting  and  Reassembly  (SAR)  layer  is  responsible  for  differ- 
ent functions  depending  on  whether  it  is  at  the  receiving  or  transmitting  end  of  the 
network.  At  the  transmission  end  of  the  network,  the  SAR  segments  large  data  pack- 
ets into  48-byte  segments.  Each  48-byte  segment  is  passed  down  to  the  ATM  layer 
where  they  are  placed  into  individual  ATM  cells.  At  the  receiver  end  of  the  network, 
the  SAR  reassembles  the  48-byte  segment  into  the  large  data  packet  and  forwards  the 
large  data  packet  to  the  receiver's  application  layer. 

c.  Transporting  ATM  cells  across  an  ATM  Network 

After  the  AAL  layer  has  converted  calls  from  ATM  and  non-ATM  into 
48-byte  segments,  the  cells  are  transported  from  source  to  the  receiver.  Before  the  cells 
can  be  transmitted  across  the  physical  layer,  all  ATM  switches  between  the  source 
and  destination  must  establish  a  connection.  This  section  describes  the  process  for 
connection  setup  when  a  physical  route  exists  from  source  to  receiver  and  a  special 
virtual  circuit  exists  for  signaling  within  that  ATM  network. 
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Virtual  circuits  are  established  by  using  the  special  signaling  circuit  and 
the  six  message  types  defined  in  Table  IV  [Ref.  7].  A  signaling  message  may  be  sent 
by  a  host  (source  or  receiver)  or  by  switches  within  the  network.  A  call  request  is 
a  signal  from  a  higher  level  application  layer  to  the  AAL  layer  indicating  that  data 
needs  to  be  sent  across  the  network.  A  call  request  begins  when  the  source  host  sends 
a  SETUP  message  over  the  signaling  circuit;  this  process  is  depicted  in  Figure  9. 
The  first  switch  in  the  network  then  sends  a  SETUP  message  to  the  next  switch  in 
the  network  and  sends  a  CALL  PROCEEDING  back  to  the  source.  As  the  SETUP 
message  works  its  way  through  the  network,  each  switch  forwards  a  SETUP  message 
to  the  next  switch  and  sends  a  CALL  PROCEEDING  back  to  the  previous  switch. 


Message 

Meaning  at  Host 

Meaning  within  Network 

SETUP 

Request  a  circuit 

Incoming  call 

CALL  PROCEEDING 

Network  saw  call 

Attempted  to  establish 
call 

CONNECT 

Network  accepts  call 

Requested  call  was 
accepted 

CONNECT  ACK 

Connect  message  received 

Call  established 

RELEASE 

Terminating  the  call 

Call  terminated 

RELEASE  COMPLETE 

Ack  for  RELEASE 

Ack  for  RELEASE 

Table  IV.  ATM  Messages  used  for  connection  establishment  and  release  (From  [Ref. 
7])- 


When  the  SETUP  message  finally  reaches  the  destination  ATM  Switch, 
the  destination  transceiver  responds  with  a  CONNECT  message  if  the  destination 
accepts  the  call  request.  The  CONNECT  message  works  its  way  back  to  the  source  in 
a  manner  similar  to  the  SETUP  message,  except  in  the  reverse  order.  At  each  switch 
within  the  network,  a  CONNECT  ACK  message  is  sent  to  the  previous  switch.  When 
the  CONNECT  message  arrives  at  the  source,  the  source  also  sends  a  CONNECT 
ACK  message  to  the  previous  switch  in  the  network. 
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Terminating  a  virtual  circuit  is  simpler  than  establishing  it.  The  source 
sends  a  RELEASE  message  to  the  first  switch  in  the  network.  This  message  propagates 
through  the  network  with  a  RELEASE  ACK  message  sent  at  each  hop  along  the  route. 


Uplink 


Dnlink 


WFA  Switch 


Destination 


Setup 
Call  Proceeding 


(a)  Call  Establishment  Sequence 


Release 
ReleaseCornEleie_ 


Release 
ReleiseComEWe. 


Release 
ReleaseComtieie, 


(b)  Call  Release  Sequence 

Figure  9.  (a)  The  sequence  of  signaling  messages  for  establishing  an  ATM  virtual 
channel,  (b)  The  sequence  of  signaling  messages  to  release  an  ATM  virtual  channel 
(From  [Ref.  7]). 
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III.         OVERVIEW  OF  THE  BADD  PROGRAM 
A.      OVERVIEW 

We  first  provide  a  general  description  of  The  Battlefield  Awareness  and 
Data  Dissemination  (BADD)  system.  Subsequent  sections  of  this  chapter  provide 
a  more  detailed  description  of  its  major  components  [Ref.  8].  The  BADD  project 
is  an  Advanced  Concepts  Technology  Demonstration  (ACTD)  sponsored  by 
the  Defense  Advanced  Research  Projects  Agency  (DARPA).  BADD  uses 
commercial  off-the-shelf  (COTS)  systems  to  support  the  U.S.  military's  need  for  total 
battle  awareness,  that  is,  to  provide  information  where  it  is  needed,  in  the  correct 
format,  and  in  a  timely  and  cost  effective  manner.  The  goal  of  BADD  is  to  empower 
war-fighters,  from  the  Task  Force  Commander  through  the  Battalion  Commander  and 
below,  with  information.  Such  information  will  be  delivered  using  advanced  dissem- 
ination technologies.  The  BADD  system  consist  of  the  following  major  components: 

•  the  Information  Dissemination  Server  (IDS), 

•  the  Satellite  Broadcast  System, 

•  the  Tactical  System/Warfighter  Associate  (WFA),  and 

•  the  Reachback  Link. 

An  overview  of  the  interactions  of  these  components  is  depicted  in  Figure  10 
and  is  summarized  below. 

The  IDS  functions  as  the  central  repository  for  processing,  storage,  and  re- 
trieval of  data.  The  Satellite  Broadcast  System  forwards  data  from  the  IDS  to 
multiple  tactical  users,  via  satellite  communication.  Data  broadcasted  over  the  satel- 
lite link  is  collected  and  stored  at  the  tactical  units  by  a  suite  of  automation  equip- 
ment called  theWarfighter  Associate  (WFA).  The  data  is  then  made  available 
to  the  warfighter's  Local  Area  Network  (LAN)  via  the  Tactical  Internet  (TI).  The 
Reachback  Link  allows  tactical  units  to  forward  important  data,  such  as  location 

23 


information  or  unmanned  aerial  video,  back  to  the  IDS  for  timely  dissemination  to 
other  tactical  forces.  In  addition,  it  provides  a  means  for  the  tactical  units  to  re- 
quest information  from  the  IDS.  Some  units  will  not  have  a  reachback  link  available 
to  communicate  to  the  IDS  directly  and  will  relay  their  request  to  the  closest  unit 
with  reachback.  These  units  will  have  the  ability  to  "listen  in"  to  broadcasts,  filter 
out  unwanted  data,  and  save  what  they  need.  Next  we  will  examine  each  of  these 
components  in  greater  detail. 

Global  Broadcast  System 


Additional 

Data 

Repositories 


IDS 


Information  Data 
Server 


WFA 


Warfighter  Associate 


□    I 


Reachback  Link 

Figure  10.  BADD  Overview  (From  [Ref.  8]). 

B.      INFORMATION  DISSEMINATION  SERVER 

The  Information  Dissemination  Server  (IDS)  provides  management,  storage, 
and  dissemination  to  the  broadcast  uplink  facility.  The  IDS  is  located  at  DARPA's 
Advanced  High  Performance  Computing  Applications  (AHPCA)  lab  facil- 
ity. The  IDS  works  in  conjunction  with  the  Warfighter  Associate  (WFA)  to  sat- 
isfy the  information  needs  of  the  lower  echelon  commanders.  The  IDS  receives  and 
stores  information  from  in-theater  via  the  reachback  links,  and  can  access  information 
from  multiple  resources,  such  as  CNN,  national  intelligence  sources,  and  the  National 
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Weather  Service,  in  the  Washington,  D.C.  area.  It  forwards  data  to  the  field  in  two 
ways.  The  first  is  by  broadcasting  the  data  that  is  stored  locally.  The  second  way  is 
by  acting  as  an  intermediate  communication  hub,  forwarding  data  from  either  a  data 
repository  or  the  reachback  link  without  storing  the  data  locally. 

The  IDS  has  the  functionality  to  integrate  data  from  various  resources  and 
disseminate  a  more  comprehensive  view  of  the  battlefield  to  the  Battalion  Commander 
in  the  field.  One  of  the  ways  the  IDS  accomplishes  this  mission  is  through  intelligently 
prepositioning  information  at  the  WFA  for  rapid  retrieval.  Such  prepositioning  is 
referred  to  as  a  Push  operation.  Another  way  the  IDS  satisfies  the  needs  of  the  user 
is  through  a  Pull  operation.  A  pull  operation  is  when  the  IDS  forwards  information 
to  be  broadcast  in  order  to  satisfy  a  query  from  the  field  over  the  reachback  link. 

Figure  11  depicts  a  high-level  diagram  of  the  flow  of  data  between  the  major 
subcomponents  of  the  IDS.  We  will  elaborate  on  each  of  these  subcomponents  in  the 
remainder  of  this  section.  [Ref.  8] 
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Figure  11.  IDS  Components  (From    [Ref.  3]). 
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1.        Information  Sources  and  Data  Repositories 

Figure  11  shows  that  there  are  multiple  sources  of  information  coming  into  the 
IDS.  The  sources  we  enumerate  are  not  inclusive  and  are  meant  to  show  the  variety 
of  data  types  that  can  be  made  available  through  the  BADD  architecture.  Table  V 
describes  each  of  the  sources  depicted  in  that  figure.  [Ref.  3] 


Source 

Description 

IMETS 

Integrated  Meteorological  System  weather  data 
from  the  division  Tactical  Operations  Center  (TOC). 

UAV 

Unmanned  Aerial  Vehicle  broadcast  from  tactical 
units.  Forwarded  live  for  wider  dissemination. 

WHITE 
BOARD 

Commander's  Whiteboard.  Provides  graph  for 
the  commander  to  use  to  elaborate  on 
orders/instructions. 

DMA 

Defense  Mapping  Agency  map  information. 

Table  V.  IDS  Information  Sources  (From  [Ref.  3]). 

2.  Source  Interface 

The  Source  Interface  integrates  the  data  that  it  receives  from  multiple  data 
sources,  including  the  reachback  link.  To  accomplish  this  task  it  uses  FORE  ATM 
switches  that  allow  inputs  from  both  ATM  sources  and  CISCO  Routers.  CISCO 
Routers  allow  input  from  TCP/IP/UDP  sources. 

3.  Search  Manager 

The  Search  Manager  retrieves  information  from  the  remote  repositories  in  or- 
der to  satisfy  Priority  Information  Requirements  (PIR)  from  the  tactical  commander. 
To  accomplish  this  task  it  maintains  directories  indicating  which  resources  are  avail- 
able from  each  of  the  distributed  repositories. 

4.  Information  Dissemination  Repository 

The  Information  Dissemination  Repository  provides  a  very  large  (tera- 
byte to  peda-byte)  on-line  storage  capability  and  is  optimized  to  service  queries  for 
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multimedia  data.  This  subcomponent  supports  the  use  of  distributed  heterogeneous 
archives.  These  archives  can  be  geographically  separated,  can  be  forwarded  to  the  IDS 
by  different  communication  protocols  (TCP/IP/UDP),  and  can  contain  data  ranging 
from  small  text  files  to  very  large  video  files. 

5.  Information  Integration  Manager 

The  Information  Integration  Manager  correlates  data  from  the  Informa- 
tion Dissemination  Repository  in  order  to  integrate  and  validate  data  from  different 
sources.  It  also  searches  for  redundancies  in  the  data  in  order  to  eliminate  them  and 
provide  both  a  more  efficient  data  transfer  and  a  more  user-friendly  interface. 

6.  Transmission  Manager 

The  Transmission  Manager  maximizes  the  probability  of  reliable  delivery 
across  simplex,  error-prone  satellite  channels.  It  optimizes  the  dissemination  to  tactical 
commanders  by  utilizing  algorithms  and  heuristics  that  send  the  highest  priority  data 
during  peak  periods  and  smartly  push  data  during  low  utilization  periods. 

Determining  when  to  push  data  is  referred  to  as  the  Data  Staging  Problem. 
H.  J.  Siegel  and  some  of  his  Ph.D.  students  at  the  University  of  Purdue  are  working 
to  resolve  this  problem  [Ref.  9].  Their  efforts  focus  on  determining  the  best  data  to 
cache,  given: 

•  the  priority  of  data  and  its  perishablility, 

•  the  dynamic  nature  of  requests  and  network  congestion,  and 

•  limits  on  bandwidth  and  data  storage. 

They  are  examining  the  use  of  mathematical  algorithms,  such  as  Dijkstra's 
Algorithm,  to  improve  the  performance  of  BADD  transmission  management. 

C.       SATELLITE  UPLINK  AND  BROADCAST  SEGMENT 

The  Satellite  Uplink  facility  is  connected  to  the  IDS  via  high  speed  links 
(T3)  and  is  the  insertion  point  for  data  into  the  broadcast  link  connecting  the  IDS 
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to  the  Warfighter  Associate.  This  broadcast  facility  is  responsible  for  providing  effi- 
cient utilization  of  the  link  while  ensuring  that  the  priority  scheme  for  transmission  is 
not  violated.  The  broadcast  is  transmitted  over  a  geosynchronous  Ku-Band  satellite, 
providing  a  direct  link  from  the  uplink  system  to  the  battalions  in  the  field.  The 
broadcast  has  two  channels,  one  for  video  and  the  other  for  data.  The  data  channel 
is  comprised  of  numerous  data  channels  multiplexed  together  to  form  one  wideband 
channel.  Figure  12  depicts  the  interactions  of  the  major  subcomponents  of  the  Broad- 
cast Subsystem;  each  of  these  subcomponents  is  addressed  in  this  section. 


Broadcast  Segment 
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ATM  Switch 
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Figure  12.  Broadcast  Segment  (Derived  From  [Ref.  10]). 

1.        Broadcast  Management  Center 

The  Broadcast  Management  Center  (BMC)  software  is  responsible  for 
collecting  all  information  to  be  broadcast  to  BADD  tactical  users.  The  data  received 
at  the  BMC  will  include  information  requested  by  tactical  users  (warrior  pull)  and 
time-sensitive,  intelligently-selected  (smart  push)  information  for  broadcast  to  tactical 
users. 
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The  BMC  will  decide  answers  to  the  following  questions: 

•  What  information  needs  to  be  broadcast? 

•  What  priority  is  the  data  to  be  broadcast? 

•  What  bandwidth  is  needed  for  the  data? 

•  When  should  the  data  arrive  at  the  Warfighter  Associate? 

If  a  message  cannot  be  broadcast  within  the  BMC-assigned  parameters,  the 
BMC  must  review  the  information  and  determine  whether  the  information  can  be 
broadcast  at  a  lower  priority  or  whether  the  information  should  be  discarded. 

2.  Uplink  Information  Manager 

Within  the  BMC,  the  Uplink  Information  Manager  (UIM)  manages  all 
information  for  broadcast  through  the  ATM  switch.  The  UIM  is  primarily  concerned 
with  maximizing  throughput,  given  a  priority  level.  Closely  coordinating  with  the 
ATM  switch  to  determine  the  dynamic  ATM  capacity,  the  UIM  attempts  to  schedule 
all  data  transmissions  to  achieve  data  throughput  of  the  highest  priority  messages.  If 
the  UIM  cannot  schedule  the  broadcast  of  a  message  within  the  assigned  constraints, 
it  will  return  the  message  to  the  Broadcast  Manager  for  resolution. 

3.  Asynchronous  Transfer  Mode  (ATM)  Switch 

The  ATM  switch  currently  used  is  the  Integrated  Systems  Technology  (1ST) 
Low  Data  Rate  (LDR)  Model  LDR-100S  [Ref.  8].  It  supports  both  ATM  and  non- 
ATM  links,  providing  multimedia,  video  teleconferencing  (VTC),  mobile  subscriber 
equipment  (MSE),  and  tactical  packet  network  (TPN)  support.  The  system  contains 
four  special  buffers  to  minimize  the  delay  of  the  constant  bit  rate  (CBR)  traffic  and 
allow  for  smoothing  of  peak  data  rates.  It  also  contains  a  TAXI  interface  card  that 
supports  connections  for  one  serial  system  and  one  parallel  port.  The  previous  chapter 
of  this  thesis  described  the  ATM  protocol  in  detail. 
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4.  Unclassified  Video 

This  unclassified  video  consists  of  CNN  news  broadcasts,  Armed  Forces  Ra- 
dio and  Television  broadcasts,  unclassified  Unmanned  Aerial  Vehicle  broadcasts,  and 
other  unclassified  video  broadcasts.  The  current  configuration  allocates  half  of  the 
total  transmission  capability  to  transmission  of  unclassified  video. 

5.  Multiplexor  (MUX) 

The  30  Mbps  Multiplexor  will  multiplex  the  unclass  video  and  ATM  data  into 
a  single  data  stream  for  broadcast  transmission  over  the  Global  Broadcast  System. 

6.  Global  Broadcast  System 

Currently,  the  Global  Broadcast  System  (GBS)  uses  a  commercial  Telestar 
401  Ku-band  satellite  transponder,  in  geosynchronous  orbit,  that  provides  an  effective 
transmission  capacity  of  23.6  Mbps.  This  single  satellite  in  the  GBS  constellation  is 
capable  of  providing  coverage  over  the  continental  United  States. 

D.   TACTICAL  LEVEL  SUBSYSTEM 

Tactical  units  at  the  battalion  level  will  have  a  Receive  Terminal  that  consists 
of  a  satellite  antenna  dish,  an  amplifier/converter  called  a  Low-Noise  Block  (LNB) 
converter,  two  Integrated  Receiver  Decoders  (IRD)  that  provide  the  decoding  of  either 
a  data  or  video  signal  stream,  and  an  ATM  switch  that  provides  the  first  level  of  filter- 
ing, a  KG-194A  Decryption  Device,  and  the  Warflghter  Associate.  Figure  13  depicts 
a  high-level  diagram  of  the  major  subcomponents  of  the  Tactical  Level  Subsystem. 
Each  of  these  subcomponents  is  addressed  in  this  section. 

1.        GBS  Receive  Equipment 

The  receive  equipment  consists  of  a  1.2  meter  antenna  dish  connected  into 
a  Low  Noise  Block  (LNB)  converter.  The  LNB  is  a  converter  taking  the  Ku-Band 
(11.7-12.2  GHz)  satellite  transmission  and  converting  it  to  L-Band  (0.39-1.6  GHz). 
This  segment  also  includes  an  Integrated  Receiver  Decoder  (IRD)  that  converts  the 
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Figure  13.  Tactical  Segment  (Derived  From  [Ref.  8]). 
signal  to  a  parallel  data  stream  for  forwarding  to  the  ATM  Switch. 

2.  Splitter 

The  Splitter  accomplishes  one  simple  function.  It  takes  the  non-ATM  signal 
on  the  broadcast  and  splits  it  off  for  injection  into  the  tactical  internet,  while  allowing 
the  ATM  transmissions  to  pass  through  to  the  ATM  Switch.  Non-ATM  signals  include 
CNN,  AFRTS  and  other  commercial  television  broadcasts. 

3.  Downlink  Information  Manager  (DIM) 

The  Downlink  Information  Manager  (DIM)  is  the  subcomponent  of  the 
Warfighter  Associate  that  determines  whether  the  information  currently  being  broad- 
cast is  of  interest  to  the  tactical  user.  The  WFA  user  customizes  his  environment 
based  upon  a  "television  guide-like"  broadcast  sent  over  the  a  predefined  control 
channel  on  the  satellite  link  displaying  the  scheduled  broadcast.  This  function  is  crit- 
ical because  the  Warfighter  Associate  only  has  limited  local  storage  capabilities,  and 
additionally,  the  tactical  user  does  not  want  to  be  flooded  with  irrelevant  data. 
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4.  ATM  Switch 

The  switch  used  is  the  same  1ST  LDR-lOOs  that  is  used  at  the  uplink  facility. 
It  provides  all  of  the  same  functions  described  above,  but  in  support  of  reception  of 
the  ATM  broadcast  instead  of  its  transmission. 

5.  Warfighter  Associate  (WFA) 

The  Warfighter  Associate  is  the  heart  of  the  BADD  system  from  the  tactical 
commander's  perspective.  It  provides  his  local  data  repository  for  quick  access  to  the 
most  important  data.  The  WFA  also  provides  information  integration  and  battlefield 
functionality.  The  Warfighter  Associate  Workstation  is  an  Ultra-SPARC  unit  respons- 
ible for  filtering  the  incoming  GBS/BADD  data  based  upon  specific  profiles,  areas  of 
interest,  and  areas  of  operations.  Workstations  will  vary  in  their  configuration  based 
on  the  service,  but  a  typical  workstation  has  64  megabytes  of  random  access  memory 
(RAM)  and  10.4  gigabytes  (GB)  of  hard  disk  storage  with  2  GB  internal  and  8.4  GB 
on  external  disks. 

The  WFA  workstation  provides  the  following  functions: 

•  Stores  data  in  a  local  repository, 

•  Provides  users  with  applications  and  interfaces, 

•  Performs  information  integration  operations, 

•  Provides  a  graphical  display  for  battlefield  visualization,  and 

•  Provides  access  to  other  users  on  the  tactical  LAN. 

6.  Tactical  Internet 

The  Tactical  Internet  (TI)  is  a  subcomponent  of  the  Army  Battle  Com- 
mand System  (ABCS)  that  focuses  on  providing  support  for  battle  command  at 
the  brigade  level  and  below.  The  TI  is  focused  on  providing  situational  awareness  to 
warfighters  at  lower  echelons  through  the  use  of  Applique  devices.  Applique  devices 
that  are  comprised  of:   1.)   a  computer  host  and  software  package;  and  2.)  a  tactical 
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radio  system  that  provides  duplex  information  flow  between  a  platform  (i.e.,  tank,  ar- 
tillery, or  aircraft)  or  an  individual  soldier  and  the  division  level  of  command.  System 
Integration  Vans  (SIVs)  plan  and  manage  the  use  of  the  Tactical  Internet  and  take 
inputs  from  the  following  systems: 

•  Enhanced  Position  Location  Reporting  System  High  Speed  Integrated  Circuit 
(EPLRS  VHSIC), 

•  Surrogate  Data  Radio  (SDR), 

•  Single  Channel  Ground  and  Airborne  Radio  System  (SINCGARS)  System  Im- 
provement Program  (SIP), 

•  Mobile  Subscriber  Equipment  (MSE), 

•  BADD,  and 

•  Interfaces  to  Tactical  Operations  Center  (TOC)  Local  Area  Networks. 

E.       THE  REACHBACK  SUBSYSTEM 

The  Reachback  Link  provides  the  connectivity  from  the  tactical  unit  to  the 
IDS  and  has  two  different  sublinks.  A  Trojan  Spirit  Satellite  communication  system 
provides  an  aggregate  transmission  rate  of  1.544  Mbps  from  the  Brigade  TOC  to  the 
IDS  LAN.  This  first  system  utilizes  an  unclassified  ethernet-based  sublink  running 
the  IP  protocol.  It  requires  a  Tactical  End-to-End  Encryption  Device  (TEED) 
because  it  tunnels  through  a  an  operationally  classified  network.  Unmanned  aerial 
vehicle  imagery,  operational  and  intelligence  overlays,  and  IMETS  data  are  sent  over 
this  sublink.  The  latest  testing  results  from  an  exercise  in  November  1996  required 
that  the  largest  packet  size  transported  from  the  Brigade  WFA  to  the  IDS  was  1472 
bytes.  The  average  round  trip  time  for  a  64-byte  packet,  from  the  Brigade  WFA 
through  the  reachback  link  and  broadcast  link  back  to  the  WFA,  was  564  ms  [Ref. 
11]. 

The  second  system  is  ATM-enabled  sublink  and  uses  a  KG-194A  encryption 
device  to  provide  secure  data  transmission.  It  operates  at  768  Kbps  and  sends  one- 
way video  stream  and  one-way  collaborative  planning  to  disseminate  the  Brigade 
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Commander's  Intent  with  real-time  video,  audio,  and  electronic  whiteboarding.  The 
round  trip  time  for  a  64-byte  packet  on  this  subnet  was  808  ms.  Jeffrey  Carpenter  and 
Jim  Galanis,  Electronics  Engineers  with  the  US  Army  Communications-Electronics 
Command  (CECOM),  recommended  examining  the  effects  of  reducing  the  bit  rate  to 
384  Kbps  in  order  to  provide  the  Ethernet  sublink  with  more  bandwidth,  based  on 
their  November  1996  experience  [Ref.  11]. 

Figure  14  depicts  a  high-level  diagram  of  the  major  subcomponents  of  the 
Reachback  Subsystem.  Each  of  these  subcomponents  is  addressed  in  this  section. 
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Figure  14.  Reachback  Components 
1.        Surrogate  Digital  Radio 

The  Surrogate  Digital  Radio  (SDR)  is  a  state-of-the-art  digital  radio  that 
provides  communication  between  the  TOCs,  the  alternate  TOCs,  and  command  and 
control  platforms  [Ref.    8].    It  has  two  major  subcomponents;  a  secure  packet  radio 
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(SPR)  and  a  wireless  integrated  services  digital  network  interface  unit  (WIU).  The 
SPR  is  a  spread  spectrum  modulation  radio  that  operates  in  the  UHF  range  and  has  a 
data  throughput  capacity  of  190  Kbps  and  embedded  communications  security.  The 
WIU  is  an  80486  lightweight  computer  providing  a  synchronous  serial  communication 
card  that  interfaces  with  the  SPR  and  the  TOC's  ethernet  LAN. 

2.  Brigade  ATM  Switch 

The  BDE  ATM  Switch  provides  a  tactical  ATM  backbone  switching  support 
for  all  tactical  users.  The  switch  provides  connections  for  wideband  fiber  optics,  syn- 
chronous optic  network  (SONET)  radios,  employed  tactical  digital  radios,  and  digital 
transmission  group  (DTG)  network  interfaces.  The  LDR-100,  which  was  described 
earlier,  is  once  again  the  chosen  hardware  for  this  switch. 

3.  Trojan  Spirit 

The  Trojan  Spirit  provides  secure  satellite  voice  and  data  communications 
from  the  forces  in  the  field  back  to  the  IDS  [Ref.  12].  It  is  a  highly  mobile  system 
mounted  on  the  back  of  a  High  Mobility  Military  Wheeled  Vehicle  (HMMWV)  Shelter 
with  a  2.4  meter,  C  through  Ku-band,  Satellite  Antenna.  It  tows  a  5.5  meter  X-Band 
satellite  communication  antenna  mounted  on  an  accompanying  trailer.  It  can  provide 
14  channels  of  digital  voice  or  support  digital  data  subscribers  over  a  Tl  link  (1.544 
Mbps). 

4.  Satellite  System 

The  Trojan  Spirit  transmits  its  data  to  a  variety  of  satellite  platforms  including 
INTELSAT,  GSTAR,  and  PANAMSAT.  Transmissions  on  these  frequencies  and  other 
satellite-lettered  bands  are  listed  in  Table  VI. 

5.  Fort  Belvoir  Trojan  Switch 

The  Fort  Belvoir  Trojan  Switch  receives  data  from  the  Trojan  Spirit  in  the  field 
and  forwards  data  via  Defense  Information  Systems  Network  Leading  Edge  Services 
(DISN  LES). 
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Letter 
Design 

Band 

Freq  Range 

(GHz) 

Bandwidth 

(MHz) 

Use 

L 

UHF 

0.39-1.6 

50 

Commercial,  Military 

S 

UHF/ 
SHF 

1.65-5.2 

90 

Tracking,  Telemetry 
and  Command 

c 

SHF 

3.9-6.2 

500 

Commercial 

X 

SHF 

5.2-10.9 

500 

Military 

Ku 

SHF 

10.9-17.25 

500 

Commercial 

Ka 

SHF 

17.5-30 

2500 
1000 

Commercial 
Military 

Table  VI.  Satellite  Lettered  Band. 

6.  AHPCA  ATM  Switch 

The  AHPCA  ATM  Switch  in  Arlington,  Virginia  processes  the  signals  from 
the  Fort  Bel  voir  switch  and  forwards  them  to  the  proper  location  within  the  IDS.  The 
FORE  ASX-200  BX  ATM  switch  provides  the  capabilities  to  function  as  a  LAN  back- 
bone [Ref.  13].  These  switches  provide  advanced  reliability  and  fault  tolerance,  and 
can  support  up  to  24  clients,  servers,  and  LAN  devices  such  as  hubs,  routers  or  LAN 
switches.  They  execute  ForeThought  Internetworking  Software  that  provides  connec- 
tion management  features  such  as  on-demand  switched  virtual  circuits  (SVCs),  both 
User  Network  Interface  (UNI)  and  Network  Network  Interface  (NNI),  and  transparent 
support  for  existing  LAN  applications  that  use  IP-over-ATM  and  LAN  emulation. 

7.  Summary 

We  have  now  reviewed  all  current  components  and  subcomponents  of  the 
BADD  Program.  We  want  to  emphasize  that  this  is  a  dynamic  experimental  ar- 
chitecture with  components  being  added  and  removed.  Our  description  of  the  system 
should  be  viewed  as  a  single  instantiation,  as  of  April  21,  1997.  Individual  components 
and  even  entire  subsystems  may  change.  In  the  next  chapter  we  review  some  of  the 
scheduling  algorithms  that  we  considered  to  integrate  into  the  BADD  Architecture. 
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IV.         INTELLIGENT  SCHEDULING 
A.      INTRODUCTION 

In  Chapter  II  we  described  ATM's  signaling  procedures  for  virtual  channel 
setup  and  tear-down.  In  this  chapter  we  will  examine  the  application  of  some  com- 
monly used  scheduling  heuristics  that  we  expect  will  improve  the  throughput  and 
fairness  of  the  BADD  network's  ATM  configuration.  Some  of  these  heuristics  are 
used  in  the  U.S.  Navy's  SmartNet  Scheduler  [Ref.  14]. 

In  a  standard  ATM  implementation,  the  request  to  establish  a  channel  contains 
a  description  of  the  requirements,  which  includes  the  requested  Quality  of  Service 
(QOS)  and  the  Peak  Cell  Rate  (PCR).  As  the  setup  request  travels  through  the  net- 
work, resources  are  allocated  to  support  the  virtual  channel.  Normally,  these  virtual 
channels  are  created  as  needed  and  then  destroyed  after  the  data  transmission  com- 
pletes. This  coordination  requires  duplex  communication  between  the  sender  and  the 
receiver. 

Within  the  BADD  architecture,  the  GBS  satellite  link  provides  only  simplex 
data  communication  between  the  IDS  and  WFA  ground  stations.  The  BADD  archi- 
tecture therefore  relies  on  static  virtual  channels.  A  static  number  of  virtual  channels 
are  defined  at  the  uplink  and  downlink  ATM  switches  and  these  channels  are  static- 
ally allocated  a  particular  bandwidth  as  well  as  other  attributes,  such  as  guaranteed 
latencies.  Future  implementations  could  define  1024  static  virtual  channels  within  the 
BADD  ATM  network  [Ref.  15]. 

With  static  channels  defined,  BADD  must  employ  some  form  of  scheduling  to 
assign  a  transmission  request  to  a  specific  channel.  This  chapter  reviews  the  basic 
scheduling  problem  and  possible  solutions. 
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B.  SCHEDULING  PROBLEM 

The  problem  of  determining  the  schedule  that  optimizes  throughput  for  execut- 
ing a  set  of  heterogeneous  tasks  using  a  fixed  set  of  heterogeneous  resources  is  one  of 
the  most  difficult  and  challenging  problems  in  computer  science.  This  general  hetero- 
geneous scheduling  problem  and  other  difficult  problems  comprise  a  set  of  problems 
known  as  NP-Complete  problems.  Most  theoretical  computer  scientists  believe  the 
NP-Complete  set  of  problems  are  intractable  [Ref.  16].  For  such  problems,  heuristics 
with  polynomial  runtimes  are  applied  to  attempt  to  obtain  a  near-optimal  solution. 

In  the  next  sections  we  will  examine  some  heuristic-based  scheduling  algorithms 
we  considered  implementing  in  BADD.  We  provide  the  psuedo-code  for  each  al- 
gorithm, an  example  of  its  execution  to  enhance  understanding,  and  a  discussion 
of  its  strengths  and  weaknesses. 

C.  HEURISTIC  ALGORITHMS 

In  this  section  we  describe  some  heuristic  algorithms  and  explain  both  their 
advantages  and  disadvantages  when  applied  to  the  general  heterogeneous  scheduling 
problem.  Throughout  the  section  we  use  the  term  call  when  addressing  a  pending 
request  for  a  virtual  channel.  We  use  this  term  to  remain  consistent  with  the  termino- 
logy that  is  used  when  we  describe  the  code  for  our  OPNET  implementation  of  BADD. 
In  ATM  terminology,  a  call  refers  to  a  session  between  a  source  and  a  destination.  A 
call  can  contain  one  or  many  messages  inside  it.  A  message  is  defined  as  a  group  of 
packets  that  belong  to  one  specific  communication  application  (i.e.,  an  email  message 
or  a  database  view).  For  this  thesis,  we  assume  that  a  call  contains  only  one  message. 

1.        First  In  First  Out 

The  First  In  First  Out  (FIFO)  algorithm  is  the  simplest  algorithm.  It  assumes 
that  every  channel  can  be  used  for  every  transmission.  The  scheduler  enqueues  all 
pending  calls  onto  a  wait  queue  and  schedules  the  call  at  the  head  of  the  queue  on  the 
next  available  channel. 
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a.  FIFO  Algorithm  Specification 

The  following  is  a  general  algorithm  for  simulating  FIFO  Scheduling. 
This  algorithm  can  be  modified  if  some  calls  are  not  suited  to  some  channels. 

1.  Place  all   jobs  to   be  scheduled  in  the  time-ordered  queue, 
Job_Queue,   and  set   channel_avail_time[channel_number]   =  0  for  all 
channels 

2.  While    (Call_Queue  not   empty) 

3.  Remove  first   call   in  the  Call_Queue. 

4.  Compute  earliest  time  at  which  a  channel  will  finish 
sending  its   current  call.    Store  the  index  of  that  channel 
in   schedule_index. 

5.  Schedule  call  that  was  removed  from  Call_Queue  for 
channel [schedule_index] . 

6.  Update  channel_avail_time[schedule_index]   by  adding  to 
it  the  amount  of  time  needed  to   complete  the  removed 
call. 

7.    End  While 

b.  Examples 

Figure  15  shows  an  example  of  the  steps  for  the  simulation  of  the  FIFO 
algorithm.  There  are  three  VCs,  and  currently  there  are  three  pending  calls.  In 
step  (a),  the  call  scheduling  matrix  is  created,  which  contains  the  required  time  to 
complete  each  call  when  scheduled  on  each  of  the  virtual  channels  (VC).  We  depict 
the  completion  times  for  previously  scheduled  calls  on  each  of  the  virtual  channels 
using  a  timeline.  In  this  example,  virtual  channels  1  through  3  will  finish  at  times  11, 
15,  and  60,  respectively.  In  step  (b),  we  select  VCl  to  service  call  1  because  it  will 
be  available  at  the  earliest  time,  t  —  11.  (Notice  that  the  values  calculated  in  the  call 
scheduling  matrix  are  not  used  when  selecting  a  channel.  The  matrix  is  only  used 
to  update  the  timeline  values.)    Next  we  increment  the  timeline  to  reflect  that  call  1 
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has  been  scheduled  on  VC1.    In  step(c),  we  repeat  the  actions  of  step  (b)  with  call 

2  and  select  VC2  and  again  update  the  timeline.  Step  (d)  finishes  the  scheduling  by 

scheduling  call  3  on  VC2  and  finalizes  the  timeline  for  this  example. 
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Figure  15.  FIFO  Algorithm  Example 

c.  Strengths /Weaknesses 

The  strength  of  the  FIFO  algorithm  is  that  it  is  very  easy  to  implement. 
Its  computational  expense  is  0(n),  where  n  is  the  number  of  calls  requiring  service. 
The  weakness  of  FIFO  is  that  you  may  place  calls  on  channels  that  are  ill  suited  to 
carry  them.  The  scheduling  of  call  3  on  VC2  is  an  example  of  this  problem.  This 
selection  would  require  100  time  units  to  complete.  Selecting  either  of  the  other  virtual 
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channels  would  cause  an  earlier  overall  completion  time  for  all  of  the  calls. 

2.       Best  Fit 

The  Best  Fit  Algorithm  is  also  a  simple  algorithm.  Unlike  the  FIFO  al- 
gorithm, this  algorithm  does  not  ignore  the  criteria  that  the  user  wants  to  optimize. 
In  our  scheduling  problem,  we  attempt  to  minimize  the  time  of  which  the  last  call 
completes.  In  the  following  example,  the  calls  are  scheduled  in  the  order  in  which 
they  are  generated.  For  each  call,  the  channel  that  would  yield  the  minimum  duration 
time,  neglecting  calls  already  scheduled  or  in  progress,  is  scheduled  to  carry  that  call. 

a.  Best  Fit  Algorithm  Specification 

The  following  is  a  general  algorithm  for  implementing  the  Best  Fit  Al- 
gorithm. 

1.  Place  all  calls  to  be  scheduled  in  the  time -ordered  queue, 
Call_Queue,   and  set   channel_avail_time[channel_number]   =  0  for  all 
channels 

2.  While   (Call_Queue  not   empty) 

3.  Remove  first   call   in  the  queue. 

4.  Ignoring  calls   already  in  progress  and  those  already 
scheduled,   compute  fastest  time  in  which  a  channel  can  send 
this   call.      Store  index  of  that   channel   in  schedule_index. 

5.  Schedule  call  that  was  removed  from  Call_Queue  for 
channel [schedule.index] . 

6.  Update  channel_avail_time[schedule_index]   by  adding  to 
it  the  amount  of  time  needed  to  complete  the  removed 
call. 

7.    End  While 

b.  Examples 

Figure  16  displays  an  example  of  the  steps  for  the  execution  of  the  Best 
Fit  Algorithm.    In  step  (a),  each  element  of  the  matrix  contains  the  required  time 
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to  send  the  call  when  scheduled  on  each  of  the  virtual  channels  (VC).  We  depict  the 
completion  times  for  previously  scheduled  calls  on  each  of  the  virtual  channels  using 
a  timeline.  In  this  example,  virtual  channels  1  through  3  will  again  finish  at  times  11, 
15,  and  60,  respectively.  In  step  (b),  for  call  1,  we  select  the  virtual  channel  with  the 
smallest  duration  time.  In  this  example  it  is  VC3.  Next  we  update  the  timeline  and 
remove  call  1  from  the  call  scheduling  matrix.  In  step  (c),  we  repeat  the  actions  of  step 
(b)  with  call  2,  select  VC2,  and  update  the  timeline.  Step  (d)  finishes  the  scheduling 
by  choosing  to  place  call  3  on  VC3  and  finalizing  the  timeline  for  this  example. 
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c.  Strengths/ Weaknesses 

The  strength  of  this  scheduling  algorithm  is  that  it  considers  the  schedul- 
ing criteria.  The  algorithm  is  still  relatively  simple,  requiring  only  a  little  computa- 
tional overhead,  however,  it  is  more  complex  than  FIFO,  being  0(nm)  where  n  is  the 
number  of  calls  and  m  is  the  number  of  channels.  The  major  weakness  is  that  the 
algorithm  does  not  consider  the  load  that  has  already  been  placed  on  each  channel. 
We  see  this  condition  in  the  example  with  the  scheduling  of  call  3  onto  VC3  when  the 
better  choice  would  have  been  to  schedule  it  on  VCl. 

3.        0{nm)  Greedy  Algorithm 

The  0(nm)  algorithm  is  a  simple,  yet  very  powerful  means  of  scheduling  calls 
onto  virtual  channels.  The  letter  n  again  represents  the  number  of  calls  and  the 
letter  m  represents  the  number  of  virtual  channels.  This  algorithm  considers  both  the 
innate  ability  of  a  channel  to  support  a  transmission  as  well  as  the  current  load  on 
each  channel. 

In  the  0(nm)  Greedy  example  that  follows,  the  scheduling  criteria  is  again 
defined  as  minimizing  the  time  at  which  the  last  virtual  channel  completes.  This 
algorithm  is  different  from  the  previous  scheduling  algorithms  because  it  bases  its 
decision  partly  on  completion  time  of  each  virtual  channel. 

a.         0(nm)   Greedy  Algorithm  Specification 
The  following  is  a  general  algorithm  for  implementing  the  0(nm)  greedy 
algorithm  for  scheduling  calls  onto  static  virtual  channels. 

1.  Place  all  calls  to  be  scheduled  in  the  time-ordered  queue, 
Call_Queue,  and  set  channel_avail_time[channel_number]  =  0 
for  all   channels. 

2.  While    (Call_Queue  not   empty) 

3.  Remove  first   call   in  the  queue. 

4.  Compute  time   at   which  this  call  would  complete  if   assigned 
to   each  channel.      Determine  the  minimum  of  these  completion 
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times.   Store  the  index  of  the  channel  that  yields  the 
earliest  completion  time  in  schedule_index. 

5.  Schedule  the  call  that  was  removed  from  Call_Queue  for 
channel [schedule_index] . 

6.  Update  channel_avail_time[schedule_index]  . 
7.  End  While 

b.  Examples 

Figure  17  displays  an  example  of  the  steps  for  the  execution  of  the 
0{nm)  Greedy  Algorithm.  In  step  (a),  the  elements  of  the  matrix  contain  the  required 
time  to  send  a  call  when  scheduled  on  each  of  the  virtual  channels  (VC).  We  depict  the 
completion  times  for  previously  scheduled  calls  on  each  of  the  virtual  channels  using 
a  timeline.  In  this  example,  virtual  channels  1  through  3  will  finish  at  times  11,  15, 
and  60,  respectively.  In  step  (b),  we  add  the  runtime  from  the  matrix  to  the  VC  finish 
time  on  the  timeline  for  the  first  call  only.  We  also  add  these  values  to  the  first  row 
because  the  0{nm)  Greedy  Algorithm  schedules  the  call  with  the  earliest  completion 
time,  then  moves  on  to  schedule  later  calls.  We  also  find  that  VCl  is  the  best  choice 
because  it  has  the  earliest  completion  time,  t  =  36,  so  we  update  the  timeline  to  reflect 
this  choice.  In  step  (c),  we  repeat  the. actions  of  step  (b)  with  call  2  and  select  VC2 
and  update  the  timeline.  Step  (d)  finishes  the  scheduling  by  selecting  call  3  to  be  sent 
on  VCl  and  finalizes  the  timeline  for  this  example. 

c.  Strengths/ Weaknesses 

The  strength  of  the  algorithm  is  that  it  requires  relatively  little  overhead 
and  executes  rapidly.  This  greedy  algorithm  is  computationally  the  same  as  the  Best 
Fit  Algorithm  but  is  more  computationally  expensive  than  the  FIFO  example,  0(nm) 
vs.  O(n)  respectively.  This  algorithm  looks  at  the  ramifications  of  scheduling  each 
call  on  all  of  the  available  channels.  It  is  a  good  algorithm  for  the  user  looking  for 
modest  levels  of  improvement  with  little  processing  expense. 
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Figure  17.  0(nm)  Greedy  Algorithm  Example 

4.       An  0(n2m)  Greedy  Algorithm 

This  Greedy  algorithm  is  more  complex  than  the  O(nm)  greedy  algorithm.  It 
requires  an  evaluation  of  predicted  completion  times  for  all  calls  in  the  scheduling 
matrix,  and  it  generally  produces  better  schedules  at  the  expense  of  more  overhead 
computation. 

a.         0(n2m)   Greedy  Algorithm  Specification 
The  following  is  a  general  algorithm  for  implementing  the  0(n2m)  greedy 
algorithm  for  scheduling  virtual  channels. 

1.      Place  all   calls  to  be  scheduled  in  the  time -ordered  queue, 
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Call_Queue,  and  set  channel_avail_time [channel .number]  =  0 
for  all  channels. 

2.  While  (Call_Queue  not  empty) 

3.  Compute  time  at  which  each  call  would  complete  if  scheduled 
immediately  on  each  channel,  including  the  time  of  any  calls 
previously  scheduled  on  the  channel. 

4.  Determine  the  (call,  channel)  pair  with  the  earliest 
completion  time.  Store  the  index  of  that  channel  in 
schedule_index,  and  the  index  of  the  call  in  call_index. 

5.  Remove  selected  call  from  Call_Queue[call_index] . 

6.  Schedule  call  that  was  removed  from  Call_Queue  for 
channel [schedule_index] . 

7.  Update  channel_avail_time[schedule_index] . 
8.  End  While 

b.         Examples 

Figure  18  displays  an  example  of  the  steps  for  the  execution  of  the 
0(n2m)  Greedy  Algorithm.  In  step  (a),  the  elements  of  the  matrix  contains  the 
required  time  to  complete  each  call  if  it  is  scheduled  on  each  of  the  virtual  channels 
(VC).  We  depict  the  completion  times  for  previously  scheduled  calls  on  each  of  the 
virtual  channels  in  a  timeline.  In  this  example,  virtual  channels  1  through  3  will  finish 
at  times  11,  15,  and  60,  respectively.  In  step  (b),  we  add  the  runtime  from  the  matrix 
to  the  VC  finish  time  on  the  timeline  for  all  of  the  calls.  This  is  in  contrast  to  the 
O(nm)  Greedy  Algorithm  where  we  only  applied  values  to  the  top  row  of  the  matrix. 
Next  we  iterate  through  each  column  of  each  row  in  the  matrix  to  find  the  smallest 
value  and  flag  it  with  an  arrow.  Then  we  iterate  through  all  these  flagged  values  and 
find  the  smallest  of  these  values  and  flag  it  with  a  second  arrow.  We  find  that  VCl  for 
call  3  is  the  best  choice  because  it  has  the  earliest  completion,  t  =  21,  so  we  update 
the  timeline  to  reflect  this  choice.   Finally,  we  delete  call  3  from  the  matrix.   In  step 
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(c),  we  repeat  the  actions  of  step  (b)  by  scheduling  call  2  on  VC2  and  updating  the 
timeline.  Step  (d)  completes  the  example  by  scheduling  call  1  on  VCl  and  finalizes 
the  timeline. 
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Figure  18.  0(n2m)  Greedy  Algorithm  Example 

c.  Strengths/ Weaknesses 

The  strength  of  0(n2m)  Greedy  Algorithms  resides  in  the  more  ex- 
haustive search  through  the  entire  matrix  to  find  the  minimum  value.  This  schedule  is 
generally  better  than  the  0(nm)  Greedy  Algorithm.  The  disadvantage  of  this  greedy 
algorithm  is  that  it  requires  much  more  computation  to  determine  the  scheduling. 
This  computation  requirement  can  cause  delays  which  the  user  finds  unacceptable. 
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D.      SUMMARY 

In  this  chapter  we  examined  some  of  the  algorithms  available  in  the  SmartNet 
Scheduler  and  provided  examples  to  enhance  the  understanding  of  how  they  work.  We 
also  showed  that  they  could  be  applied  to  scheduling  calls  on  virtual  channels,  whereas 
SmartNet  applies  them  only  to  scheduling  jobs  on  high  performance  machines.  We 
will  use  two  of  the  algorithms  in  our  simulations  for  this  thesis.  The  are  the  FIFO  and 
the  0{n2m)  greedy  algorithms.  The  FIFO  algorithm  is  the  default  used  by  OPNET 
and  we  selected  the  0{n2m)  algorithm  because  it  requires  polynomial  amount  of 
computational  overhead  and  considers  both  channel  loads  and  characteristics.  The 
comparisons  of  these  two  extremes  will  allow  us  to  determine  whether  intelligent 
scheduling  is  worth  the  computational  expense.  In  the  next  chapter,  we  describe  our 
implementation  of  the  BADD  network  using  OPNET. 


48 


V.         OPNET 

A.  CHAPTER  OVERVIEW 

This  chapter  describes  Optimized  Network  Engineering  Tools  (OPNET) 

from  MIL  3  in  enough  detail  to  allow  the  reader  to  understand  how  we  use  this  state-of- 
the-art  network  modeling  tool  to  model  the  BADD  network.  The  reader  who  is  already 
familiar  with  OPNET  can  safely  skip  this  chapter.  Before  describing  OPNET's  cap- 
abilities, we  provide  a  quick  overview  of  discrete  event  simulation.  Readers  familiar 
with  this  topic  may  proceed  to  the  following  section. 

B.  DISCRETE  EVENT  SIMULATION 

Why  are  we  using  OPNET?  What  is  Discrete  Event  Simulation?  These  are 
two  excellent  questions.  The  use  of  models  in  simulations  provides  a  means  of  gaining 
understanding  of  complex  problems.  To  construct  the  models  requires  the  modeler  to 
make  simplifying  assumptions  in  order  to  reduce  the  complexity  and  size  of  the  object 
they  wish  to  model  while  preserving  the  most  important  characteristics  of  the  model. 
Models  of  physical  objects,  such  as  bridges,  have  been  used  to  gain  greater  knowledge 
of  the  stresses  associated  with  particular  structures  and  materials.  Some  of  the  same 
modeling  principles  used  with  bridges  can  be  applied  to  a  communication  network 
to  gain  an  understanding  of  that  network's  dynamic  behavior.  The  term  dynamic 
means  that  the  state  of  the  network  changes  over  time.  As  an  example,  changes  occur 
to  a  network  state  when  a  new  communication  is  placed  on  it  or  when  an  existing 
communication  completes.  One  way  to  capture  the  dynamic  nature  of  the  network  is 
to  use  a  modeling  tool,  such  as  OPNET,  that  supports  Discrete  Event  Simulation. 

To  understand  discrete  event  simulation,  the  concept  of  a  state  must  first  be 
defined.  A  state  is  a  collection  of  variables  necessary  to  describe  a  system  at  a 
particular  point  in  time.  The  "number  of  calls"  in  a  wait  queue  is  an  example  of  a 
state  variable  for  a  communication  network.   In  discrete  event  simulations,  the  state 
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variable's  values  change  instantaneously  at  distinct  points  in  time.  Discrete  event 
simulations  are  useful  for  characterizing  networks  because  the  number  of  calls  in  a 
system  changes  at  discrete  times  when  a  call  arrives  or  when  a  call  is  serviced  by  the 
network.  The  user  is  only  interested  in  these  specific  points  in  time  which  are  called 
events(because  the  state  of  network  does  not  change  continuously).  Discrete  event 
simulations  use  an  event  list  to  chronologically  record  when  generated  events  are  to 
take  place.  The  time  when  state  changes  occur  are  maintained  with  a  simulation 
clock.  By  advancing  the  simulation  clock  only  when  all  scheduled  events  for  a  time 
take  place,  discrete  event  simulations  can  support  the  execution  of  concurrent  events 
in  the  simulation.  The  ability  to  execute  multiple  events  at  the  same  time  is  a  highly 
desirable  feature  because  it  allows  the  user  to  design  more  realistic  simulations. 

Figure  19  depicts  the  flow  of  control  through  the  execution  of  a  discrete  event 
simulation.  At  time  t  =  0,  the  main  program  calls  the  initialization  routine  that  sets  the 
simulation  clock,  initializes  system  states,  initializes  the  empty  event  list,  generates  the 
first  event,  and  places  it  in  the  list.  After  the  initialization  routine  is  complete,  the  main 
program  invokes  a  Simulation  Kernel  that  takes  the  first  event  off  the  time-ordered 
list,  advances  the  clock  to  the  time  of  this  removed  event,  and  invokes  the  Event 
Handler  corresponding  to  this  event.  As  an  event  handler  executes,  it  generates  new 
events  and  places  those  in  the  event  queue.  Also,  during  the  execution  of  an  event 
handler,  the  system  state  is  updated  and  statistical  counters  are  maintained.  When 
an  event  handler  completes,  control  is  returned  to  the  simulation  kernel.  A  program 
implements  simulation  termination  in  any  of  three  ways:  (i)  when  the  simulated  time 
reaches  a  certain  value,  (ii)  when  a  statistical  counter  reaches  a  particular  value,  or  (iii) 
in  unusual  circumstances,  when  the  event  list  is  empty.  When  a  simulation  completes, 
it  computes  the  statistics  of  interest  and  writes  a  report  for  analysis.  We  presented  a 
very  high  level  view  of  discrete  event  simulations  and  the  interested  reader  can  consult 
textbooks  for  a  more  detailed  discussion  of  this  topic.  [Ref.  17] 
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Figure  19.  Discrete  Event  Simulation  Flow  Control  (From  [Ref.  17]). 


51 


C.      OPNET  OVERVIEW 

OPNET  is  a  robust  and  comprehensive  engineering  system  capable  of  simulat- 
ing large  communication  networks  with  detailed  protocol  modeling  and  performance 
analysis.  OPNET  is  an  object-oriented  modeling  system  that  allows  the  user  to  easily 
traverse  through  a  multi-level  network  model  to  perform  refinements  and  modifica- 
tions in  support  of  an  iterative  design  approach  [Ref.  4].  Figure  20  shows  OPNET's 
Hierarchy  where  the  Network  Layer  is  built  from  Sub-Networks,  Sub-Networks 
are  built  from  Nodes,  and  the  Nodes  are  built  from  Process  Models. 
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Figure  20.  OPNET  Hierarchy  (Derived  From  [Ref.  4]). 

The  Network  Layer  through  the  Node  Layer  focus  on  the  topography  of  the 
network.  This  allows  the  user  to  visualize  the  structure  and  interactions  between 
objects  in  the  network  at  finer  levels  of  abstraction  as  we  move  down  through  the 
layers.  While  the  Network  Layer  in  our  example  only  shows  a  geographic  relationship 
of  the  network  between  Flagstaff  and  Boston,  the  Node  module  provides  much  greater 
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detail  by  indicating  the  functionality  of  the  node  by  using  a  naming  convention  (i.e., 
the  server  node  with  the  name  S6). 

The  Process  Model  defines  the  behavior  for  processors  and  queue  modules  in 
OPNET.  A  process  is  an  instance  of  a  process  model  and  operates  within  an  OPNET 
processor  module.  In  Figure  20,  we  show  that  the  server  processor  module  has  various 
states  within  its  process  model  (init,  wait,  receive,  and  transmit).  These  states,  and 
the  transitions  between  them,  reflect  the  specific  behaviors  that  occur  repeatedly  in  a 
server.  Now  that  the  reader  has  a  general  understanding  of  the  hierarchical  framework, 
we  describe  how  OPNET  supports  discrete  event  simulation. 

D.      OPNET  SUPPORT  OF  DISCRETE  EVENT  SIMULA- 
TION 

OPNET  supports  discrete  event  simulation  of  network  loads,  allowing  the  user 
to  easily  modify  attributes  and  providing  analysis  tools  with  which  to  examine  network 
performance,  either  globally  or  at  at  specific  points  in  a  network.  OPNET  uses  a 
Simulation  Kernel  to  run  the  simulation  by  controlling  the  addition  and  deletion  of 
events  to  a  single  event  list.  The  simulation  kernel  and  process  models  can  generate 
events  for  addition  to  the  event  list  using  OPNET  Kernel  Procedures  (KPs). 
KPs  also  allow  the  user  to  gain  information  about  the  event  list,  for  example,  the 
time  of  the  next  scheduled  event.  Events  can  be  added  to  the  event  list  for  the  current 
simulation  time  or  for  any  time  in  the  future.  (Events  from  the  past  cannot  be  added  to 
the  list.)  Figure  21  illustrates  an  OPNET  event  list.  The  boxes  in  the  figure  represent 
events  scheduled  on  the  list.  We  have  highlighted  OPNET's  ability  to  support  multiple 
events  on  the  list  which  are  to  occur  at  the  same  time.  It  accomplishes  concurrent 
execution  by  executing  all  events  scheduled  for  the  same  time  before  advancing  the 
simulation  clock  to  the  time  of  the  next  event  on  the  list.  We  also  highlight  the  fact 
that  the  time  between  events  on  the  list  can  be  variable  which  is  characteristic  of  using 
Next-Event  time  advance  with  simulation  time. 
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Figure  21.  Distribution  of  Events  on  an  Event  List  (From  [Ref.  4]). 

The  user  accesses  the  KPs  within  processes  using  the  Process  Editor.  The 
Process  Editor  will  be  discussed  in  greater  detail  later  in  this  chapter;  however,  we 
will  discuss  its  interaction  with  the  simulation  kernel  now.  As  we  stated  earlier,  the 
simulation  kernel  adds  events  to  the  event  list.  This  is  accomplished  when  the  kernel 
receives  interrupts.  Interrupts  can  come  from  the  kernel  itself  or  from  the  process 
models.  Examples  of  kernel  interrupts  are  those  that  signal  the  beginning  and  ending 
of  the  simulation.  Examples  of  process  models  calling  interrupts  include  one  that 
causes  a  process  to  transition  from  one  state  to  another  after  a  specified  delay,  one 
that  allows  a  process  to  signal  another  to  perform  an  operation,  and  one  that  sends 
a  packet  to  another  process  and  notifies  that  process  when  the  packet  arrives.  For 
example,  the  last  interrupt  described  above  would  be  called  in  the  transmit  state  found 
in  Figure  20.  In  the  following  section  we  will  discuss  the  Process  Editor  in  more  detail, 
describing  how  to  use  it  to  construct  finite  state  machines.  We  now  examine  the  tools 
OPNET  provides  to  build  network  models  and  simulate  network  loading. 

E.       OPNET  TOOLS 

OPNET  supports  network  design,  testing,  and  analysis  with  the  eight  tools 
listed  in  Table  VII.  All  of  OPNET's  tools  are  available  through  an  advanced  graphical 
user  interface  (GUI)  known  as  the  MIL  3  User  Interface.    It  provides  support 
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utilities  in  each  of  the  tools  that  are  accessed  via  action  buttons.  Some  of  these 
utilities  are  common  to  all  of  the  editors,  such  as  the  utilities  that  read  and  write  files 
and  print  reports  and  graphics.  Other  utilities  are  unique  to  a  particular  tool.  We 
will  only  address  the  most  commonly  used  utilities  within  each  of  the  tools.  Now  we 
will  describe  the  function  of  each  of  these  tools. 


Tool 

Purpose 

Network  Editor 

Design  Overall  Network  Topology 

Node  Editor 

Design  and  Edit  Nodes  in  Network 

Process  Editor 

Design  and  Modify  State  Diagrams  of  Nodes 

Parameter  Editor 

Modify  Parameters  of  Links  and  Packets 

Probe  Editor 

Set  Probes  to  Collect  Network  Statistics 

Simulation  Tool 

Configure  and  Run  Simulations  on  Network 

Analysis  Tool 

Evaluate  Data  Collected  during  Simulation 

Filter  Editor 

Define  numerical  processing  filters  to 

take  multiple  inputs  and  produce  an  output 

Table  VII.  OPNET  Tools  (Derived  From  [Ref.  4]). 

1.        The  Network  Editor 

The  Network  Editor  is  used  to  construct  the  user's  network  models.  Its  main 
purpose  is  to  define,  at  a  high  level,  the  topology  of  the  network.  Networks  in  OPNET 
consist  of  communication  nodes  connected  by  point-to-point  links,  busses,  and  radio 
links.  The  nodes  and  links  can  be  grouped  together  to  form  subnetworks.  These 
subnetworks  can  then  be  viewed  as  single  objects  within  a  larger  network,  rendering 
simpler  models  that  are  more  easily  understood. 

The  most  commonly  used  utility  in  the  Network  Editor  is  an  Object  Palette. 
It  allows  the  user  to  configure  a  workspace  to  contain  only  those  objects  that  are 
necessary  for  the  network  currently  under  development.  For  example,  when  designing 
an  ATM  network,  there  is  no  need  for  models  supporting  Ethernet.  This  utility  also 
includes  a  Rapid  Configuration  constructor  to  allow  the  user  to  quickly  build  the 
most  common  networks  such  as  a  star  or  bus  topology.    Also  useful  is  the  Carto- 
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graphic  Background  that  allows  the  user  to  load  maps  as  a  background  for  their 
networks. 

Figure   22  displays  the  Network  Editor,  with  the  Object  Palette  open,  and  an 
example  network  model. 


Thg! 


\=^;'opnet;- 


OPNET  Modeler  3.0.A  (c)  1996  MIL  3,  Inc.    Network  Editor:  clark_badd_top3 


Figure  22.  OPNET  Network  Editor.  From    [Ref.  7] 

2.        Node  Editor 

The  Node  Editor  is  used  to  construct  models  of  nodes  within  the  network.  It 
provides  magnification  to  the  network  model,  showing  more  details  of  the  network 
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topology  at  a  local  level.  Nodes  are  created  by  connecting  modules  (i.e.,  processors, 
queues,  data  generators,  receivers  and  transmitters)  together  with  packet  streams 
and  statistic  wires.  Packet  streams  allow  packets  to  be  sent  between  the  output 
interface  of  a  source  module  and  the  input  interface  of  the  destination  module.  Statistic 
wires  support  the  flow  of  numerical  data  by  connecting  output  statistics  of  a  source 
module  to  the  input  statistic  of  the  destination  module.  The  most  commonly  used 
utilities  are  listed  in  Table  VIII. 


Action  Button 

Purpose 

Processor 

General  purpose,  programmable  object, 

whose  behavior  is  specified  by  Process  Modules 

Ideal  Generator 

Used  to  generate  random  packets 

Clock  Generator 

Used  to  generate  packets  aligned  with  a 
synchronous  clock 

Queue 

Used  to  queue  up  packets  awaiting  service 

Pt-Pt/Bus  Receiver 

Used  to  receive  packets 

Pt-Pt/Bus  Transmitter 

Used  to  transmit  packets 

Table  VIII.  OPNET  Node  Editor  Action  Buttons  (Derived  From  [Ref.  4]). 

The  Node  Editor  allows  the  user  to  create  and  assign  specific  naming  attributes 
to  the  modules  that  comprise  their  network.  An  example  would  be  assigning  the  name 
"server"  to  a  user  defined  module.  The  construction  of  a  node  provides  a  skeleton  of 
the  modules  required  to  accomplish  its  particular  function  (i.e.  processor,  generator, 
or  queue).  To  fill  in  the  skeleton  we  use  the  finite  state  machines  found  in  the  Process 
Editor. 

3.        Process  Editor 

The  Process  Editor  is  the  most  important  component  of  OPNET.  The  Process 
Editor  allows  the  user  to  create  state  diagrams  for  the  processor  and  queue  modules 
defined  in  their  Nodes.  State  diagrams  are  useful  when  modeling  networks  because 
of  the  nature  of  networks.    Networks  are  dynamic,  and  transition  between  a  finite 
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number  of  well-defined  states  (i.e.  idle,  transmitting  data,  receiving  data).  Networks 
do  not  create  new  states  over  time.  They  rotate  between  a  finite  number  of  states 
based  on  responses  to  specific  stimuli.  State  diagrams  allow  the  user  to  abstract  these 
states,  and  the  transitions  that  cause  them  to  move  between  states,  into  a  form  that  is 
easily  understood.  In  addition,  state  diagrams  are  easily  integrated  into  discrete  event 
simulations  because  the  states  of  a  process  model  can  easily  be  correlated  to  events 
in  a  simulation.  A  more  detailed  explanation  of  state  diagrams  is  found  in  Hopcroft 
and  Ullman's  book  [Ref.  18]. 

Process  Models  represent  the  logic  embodied  in  the  communications,  hard- 
ware, network  protocols,  and  algorithms  that  comprise  the  network.  It  is  important 
to  note  that  Process  Models  define  the  states  of  processors  and  that  these  two  terms 
are  not  interchangeable.  To  use  an  analogy,  the  Nodes  in  a  network  are  similar  to  the 
skeletal  structure  of  a  human.  The  process  models  of  a  network  provide  movement 
in  the  network  states  just  as  the  muscles  and  tendons  that  attach  to  the  bones  on  the 
skeleton  make  movement  possible  in  a  human.  A  processor  is  similar  to  the  shell  of 
an  non-descript  muscle.  It  requires  further  behavioral  definition,  through  the  use  of 
state  diagrams,  to  describe  its  specific  function. 

The  Process  Editor  uses  Proto-C,  a  language  that  combines  graphical  state 
transition  diagrams,  embedded  C  language  data  items  and  statements,  and  a  library 
of  kernel  procedures  to  provide  commonly  needed  functionality  for  modeling  commu- 
nication networks  and  information  processing  systems.  The  process  editor  allows  the 
user  to  view  this  code  using  the  action  buttons  listed  in  Table  IX. 

Figure  23  displays  the  Process  Editor  with  a  state  diagram  as  a  traffic  gen- 
eration module.  OPNET  state  transition  diagrams  are  composed  of  both  state  and 
transition  components.  In  the  next  portion  of  this  section  we  will  describe  the  attrib- 
utes of  these  components  that  allow  the  user  to  define  protocols  in  support  of  discrete 
event  simulations. 

States  may  have  associated  with  them  actions  to  be  executed  upon  entry  into 
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Action  Button 

Purpose 

Edit  State 
Variables 

Allows  declaration  and  modification  of  state 
variables  that  represent  persistent  counters,  routing 
tables,  etc.  State  variables  can  only  be  modified  by 
explicit  assignment  statements  by  the  process  itself. 

Edit  Temp 
Variables 

Allows  declaration  and  modification  of  temporary 
variables  used  for  "scratch"  storage 
in  calculations  (non-persistent). 

Edit  Header 
Block 

Allows  declaration  and  modification  of  global 
variables..  Global  variables  allow  multiple  processes  to 
access  them  creating  dependencies  among  processes 

Edit  Function 
Block 

Allows  editing  and  declaration  of  functions  that  support 
recurring  calculations 

Edit  Diagnostic 
Block 

Used  to  indicate  which  state  variables  should  be 
monitored.  Used  for  debugging. 

Table  IX.  OPNET  Process  Editor  Action  Buttons  (Derived  From  [Ref.  4]). 

the  state,  (called  enter  executives),  and  when  exiting  the  state,  (called  exit  ex- 
ecutives). Calls  to  OPNET  defined  functions,  or  C-code  written  by  the  user,  cause 
the  execution  of  these  actions. 

OPNET  classifies  states  in  a  process  model  to  be  either  forced  or  unforced. 
Unforced  states  allow  a  pause  in  execution  between  the  enter  executives  and  the  exit 
executives.  In  other  words,  once  the  enter  executives  of  an  unforced  state  are  com- 
pleted, the  simulation  kernel  can  take  control  and  execute  another  event.  While  an- 
other event  is  being  processed  for  another  process,  this  process  remains  in  the  unforced 
state.  Eventually  the  simulation  kernel  will  regain  control  again  and  signal  the  process 
to  execute  its  corresponding  exit  executives.  Forced  states  do  not  permit  the  simula- 
tion kernel  to  execute  between  the  enter  and  exit  executives.  Since  forced  states  do 
not  relinquish  control  to  the  simulation  kernel,  OPNET  requires  every  process  to  have 
at  least  one  unforced  state. 

Transition  for  OPNET  are  classified  either  as  conditional  or  non-conditional. 
Conditional  transitions  occur  when  a  condition  is  placed  on  a  transition,  such  as  the 
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*i,.t»ort>.  ^     [OPNET  Modeler  3.0.A  (c)  1996  MIL3,  Inc.    Process  Editor: ams_traf_gen 


Figure  23.  OPNET  Process  Editor.  From    [Ref.  4] 

CALL-START  condition  between  the  IDLE  and  START  states  in  Figure  23.  In 
this  example,  a  call-start  signal  must  be  received  for  the  transition  to  occur.  The 
transition  between  the  INIT  and  the  CONFIG  states  in  the  same  figure  depicts  a 
non-conditional  transition.  OPNET  uses  dashed  arcs  to  depict  conditional  transitions 
and  solid  arcs  to  depict  non-conditional  transitions. 

In  order  to  support  concurrent  operations  in  a  simulation,  OPNET  allows 
processes  to  spawn  new  processes,  called  dynamic  processes.  There  is  no  constraint 
on  the  number  of  dynamic  process  spawned  in  support  of  a  simulation.   In  the  next 
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chapter  we  will  discuss  in  detail  the  use  of  dynamic  processes  to  support  our  model 
of  the  BADD  Network. 

4.        Parameter  Editor 

The  OPNET  Parameter  Editor  provides  easy  access  to  several  other  tools  that 
can  be  used  to  edit  complex  objects.  Some  examples  of  these  complex  objects  include 
the  Packet  Formats  shown  in  Figure  24,  the  Interface  Control  Information  Format 
(ICI)  shown  in  Figure  25,  and  the  Link  Model  shown  in  Figure  26. 


!  OPNET  Modeler  3.0.A  (c)  1996  MIL  3,  Inc.     Parameter  Editor:  amj_atm_ceU 
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Figure  24.  OPNET  Packet  Format  (From  [Ref.  4]). 


OPNET  Modeler  3.0.A  (c)  1996  MIL  3,  Inc.     Parameter  Editor:  badd_caU_req_if_ici 


Figure  25.  OPNET  Interface  Control  Information  Format  (From  [Ref.  4]). 

5.        Probe  Editor 

The  Probe  Editor  is  used  to  specify  locations  where  the  user  would  like  to 
collect  data.    Probes  are  specified  prior  to  running  a  simulation.    Several  types  of 
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OPNET  Modeler  3.0.A  (c)  1996  MIL  3,  Inc.       Parameter  Editor:  badd   aon_duplex_iateJhte 


l"*w 

Supported    |j  Polocco    Icon 

l-*.~p     ™       II                 1 

1  ptdup                 yee                   ||  nt»    duplex   link 

U. 

no 

bus    t«p 

no 

imciol   value 


oil  Model 


dbu    coll 


[        R^nwrw/Marq*  AtWbwf* 


Figure  26.  OPNET  Link  Format  (From  [Ref.  4]). 


probes  and  their  functions  are  listed  in  Table  X. 


Action  Button 

Purpose 

Node 
Statistic 

Supports  collection  of  built-in 
and  user-defined  statistics 

Link 
Statistic 

Supports  collection  of  built-in  statistics 
on  link  objects  at  the  network  level 

Global 
Statistic 

Supports  collection  of  values  from 
multiple  objects  throughout  the  network 

Simulation 
Attribute 

Records  scalar  statistics  for  post-simulation 
analysis  of  simulation  outputs 

Automatic 
Animation 

Provides  programming-free  animation 
of  packet  flows  at  network  and 
node  level;  node  movement  at  network 
level;  and  state  transitions  of  a  process 

Custom 
Animation 

Provides  custom  animation  within  process 
models  and  link  models  (requires  user 
programming) 

Statistic 
Animation 

Provides  programming-free  animation  depicting 
statistics  through  the  simulation 

Table  X.  OPNET  Probe  Editor  Action  Buttons  (Derived  From  [Ref.  4]). 

6.        Simulation  Tool 

OPNET  provides  a  user-friendly  graphical  interface  with  which  the  user  can 
run  multiple  simulations  simultaneously.    OPNET  also  allows  the  user  to  run  simu- 
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lations  from  the  command  line.  Running  simulations  from  the  command  line  can  be 
useful  for  saving  simulation  runs  and  traces  into  files  for  later  analysis.  The  com- 
mand line  interface  also  provides  a  number  of  standard  fields  that  support  unattended 
execution  of  simulations.  These  fields  are  summarized  in  Table  XL 


Field 

Purpose 

Network 

Network  Model  used  for  simulation 

Probe  File 

Name  of  Probe  File  specifying  data  collected 
during  the  simulation 

Vector  File 

Name  of  file  to  store  vector 
output  generated  by  simulation 

Scalar  File 

Name  of  file  to  store  scalar 
output  generated  by  simulation 

Seed 

Allows  user  to  vary  seed  to  gain 
statistical  confidence  in  results 

Duration 

Maximum  duration  of  simulation 
in  simulated  seconds 

Application 
Specific 

Allows  user  to  define  values  for  promoted 
attributes  of  network  and  process  models 

Table  XI.  OPNET  Simulation  Editor  Fields  (Derived  From  [Ref.  4]). 
7.       Analysis  Tool 

The  Analysis  Tool  supports  the  display  of  data  stored  in  two  types  of  files,  the 
output  vector  files  and  the  output  scalar  files.  Output  vector  files  are  collections  of 
pairs  of  real  values.  Output  vectors  contain  the  information  from  the  simulation  and 
are  used  as  input  to  construct  traces.  Traces  are  ordered  sets  of  abscissa  and  ordinate 
pairs,  called  entries  (traces  are  similar  in  structure  to  vectors  [Ref.  4]).  OPNET  allows 
the  user  to  view  vector  information  in  panels.  A  panel  is  a  two-dimensional  time-series 
graph  format  with  the  horizontal  axis  value  representing  an  independent  variable, 
usually  simulation  time,  and  the  vertical  axis  representing  a  dependent  variable.  The 
analysis  tool  also  provides  the  ability  to  plot  multiple  traces  on  a  single  panel.  Such 
plots  are  useful  for  comparing  multiple  different  runs.   Additionally,  this  tool  allows 
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the  user  to  vary  the  scale  and  range  of  the  axes  to  focus  on  specific  segments  of  interest. 
Figure  27  shows  an  example  of  output  from  the  Analysis  Tool. 


Figure  27.  OPNET  Analysis  Tool  (From  [Ref.  4]). 

Output  scalar  files  contain  values  that  are  accrued  over  multiple  simulations. 
Examples  of  values  that  can  be  found  in  these  files  are  average  wait  times,  peak  sizes 
of  queues,  and  standard  deviations  and  means  for  end-to-end  delays. 

8.       Filter  Editor 

The  Filter  Editor  allows  the  user  to  edit  models  that  define  the  mathematical 
processing  of  simulation  results.  A  filter  model  can  be  thought  of  as  a  single  system 
that  defines  both  inputs  and  an  algorithm  for  computing  the  output.  Figure  28  de- 
picts a  schematic  of  an  implementation  of  a  general  filter  editor.  OPNET  supports  a 
hierarchical  structure  of  filtering  where  multiple  computations  are  executed  to  derive 
a  desired  value.  This  desired  value  is  derived  by  linking  the  outputs  from  multiple 
filters  together  using  filter  connections.  The  composition  of  multiple  filters  is  called 
a  macro  filter.  The  editor  also  contains  pre-defined  filters  that  the  users  can  use  to 
build  macro  filters.  These  filters  include  an  Adder,  Gain,  Multiplier,  Mean,  Average, 
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Sum,  Differentiator,  Integrator,  Exponentiator,  Logarithm,  Delay  and  Time  Window 
Filter. 

Generalized  Model  of  a  Filter 


Figure  28.  Generalized  OPNET  Filter  From    [Ref.  4] 


F.       SUMMARY 

OPNET  is  a  sophisticated  network  engineering  tool  as  seen  from  the  review  of 
its  tools  above.  These  tools  provide  us  with  a  framework  for  developing  new  variations 
of  protocols  and  testing  these  variations  with  simulations.  In  the  next  chapter  we 
explain  how  we  used  OPNET  to  model  BADD  and  intelligent  scheduling  of  the  ATM 
virtual  channels  contained  in  the  BADD  network. 
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VI.         DESIGN  OF  BADD  NETWORK  WITHIN 

OPNET 

A.  INTRODUCTION 

The  goal  of  this  work  is  to  design  a  model  of  the  BADD  network  with  OPNET 
in  order  to  simulate  and  evaluate  the  performance  of  different  network  channel  schedul- 
ing algorithms.  This  chapter  describes,  in  detail,  our  OPNET  design  of  the  BADD 
network,  in  particular,  the  design  of  static  channels  within  the  BADD's  ATM  net- 
work, the  design  and  integration  of  multiple  call  requesters,  and  the  design  of  several 
different  BADD  call  schedulers. 

This  chapter  includes  numerous  diagrams  of  nodes,  modules,  and  processes 
within  OPNET.  The  state  names  in  many  of  the  diagrams  are  truncated  by  OPNET's 
graphic  print  utility.  The  complete  state  name  is  used  in  our  descriptions  and  all 
OPNET  reports. 

Processes  are  not  included  in  node  diagrams  because  processes  are  dynamic. 
Because  we  do  not  know  the  exact  timing  or  the  exact  number  of  calls  generated  during 
a  given  simulation,  processes  are  created  dynamically  as  needed.  These  dynamic 
processes  allow  concurrent  processing  of  multiple  call  requests. 

As  stated  in  the  Chapter  VI,  OPNET  supports  multiple  events  occurring  in  the 
simulation  at  the  same  time.  OPNET  uses  dynamic  processes  to  support  this  concur- 
rency feature.  The  distinction  between  normal  processes  and  dynamic  processes  can 
best  be  drawn  from  the  following  analogy.  Regular  processes  reflect  the  hardware  in 
a  system,  they  can  only  accomplish  one  action  at  a  time.  Dynamic  processes  reflect 
actions  that  are  running  independently. 

B.  BADD  NETWORK 

Our  first  objective  was  to  use  OPNET  to  design  and  implement  a  model  of 
the  BADD  network.    Because  the  overall  BADD  network  is  extremely  complex,  we 
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scaled  our  design  to  focus  on  the  ATM  backbone  between  the  IDS  and  the  WFA.  This 
portion  of  the  network  contains  the  GBS  (satellite)  ATM  link.  As  detailed  in  chapter 
III,  this  link  reduces  the  effective  ATM  network  capacity  to  8  Mbps.  We  will  use  our 
model  to  simulate  various  scheduling  policies  to  determine  which  are  best  at  directing 
the  network  traffic  through  this  bottleneck. 

The  GBS  link  provides  only  simplex  communication.  However,  OPNET  cur- 
rently only  supports  duplex  ATM  channels.  The  subsection  titled  Network  Com- 
munication Links  describes  how  we  modified  OPNET's  duplex  communications 
links  to  closely  approximate  the  GBS's  simplex  links.  A  high  level  view  of  our  initial 
BADD  network  model  is  given  in  Figure  29. 

The  initial  BADD  model  was  developed  using  OPNET's  ATM  modules  inter- 
connected to  reflect  the  BADD  architecture.  OPNET  provides  various  ATM  modules 
to  support  the  standard  ATM  network  protocol.  Because  BADD  utilizes  ATM  in  such 
an  unusual  way,  we  selected  OPNET's  simplest  ATM  modules  and  modified  them  as 
necessary  to  support  our  model.  A  full  description  of  each  of  the  components  and 
network  modifications  is  given  in  the  remainder  of  this  section. 

In  the  subsections  below  we  will  be  describing  the  various  modules  that  com- 
prise the  four  nodes  in  Figure  29.  Quite  often  a  particular  module  may  be  used  by 
more  than  one  node.  When  we  describe  such  a  module,  we  will  note  which  other 
nodes  it  is  used  in  and  provide  a  general  description  of  its  function  and  structure.  For 
example,  in  describing  the  ATM_mgmt  module  in  the  IDS  LAN  traffic  source  node,  a 
module  that  is  also  present  in  all  of  the  other  nodes,  we  will  say  that  certain  states  may 
be  used  to  decide  whether  the  final  destination  of  a  message  is  that  node  or  another. 

1.       IDS  LAN  Subnet 

As  described  in  chapter  III,  the  IDS  consolidates  information  to  be  broadcast 
over  the  GBS  system.  For  simplicity,  we  first  modeled  the  IDS  LAN  as  a  single  traffic 
source  node.  This  initial  traffic  source  generates  constant  sized  data  packets  at  a 
constant  rate;  a  decision  we  made  to  keep  the  model  simple  until  the  overall  network 
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Figure  29.  Designed  BADD  Network  within  OPNET. 

model  functioned  properly. 

A  detailed  view  of  the  IDS  LAN  node  is  shown  in  Figure  30.  This  node  consists 
of  four  basic  components:  a  module  to  generate  calls,  an  AAL  module,  several  ATM 
modules  and  a  transmitter-receiver  pair. 


call_g':r  erator 


receiver  ATM_trans  ATM_switch         transmitter 

Figure  30.  Initial  BADD  traffic  source  node  with  single  call  .generator. 

This  node  communicates  with  other  nodes  in  the  network  through  the  transmitter- 
receiver  pair  (transceiver).  A  transceiver  is  required  for  each  communication  link. 
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a.  The  Call  Generation  Module 

The  function  of  the  call  .generator  module  is  to  generate  requests  to  send 
data  as  well  as  to  generate  the  actual  data  packets  to  be  broadcast  over  the  simulated 
BADD  network.  The  state  diagram  illustrating  the  action  of  this  module  is  shown  in 
Figure  31.  A  description  of  these  states  is  given  below. 


(default) 


(NOTTFY_COMPLETE) 

IB  config  J|| Hlsehedul 


(default)  '         j 


(default) 


(default) 


(default) 


Figure  31.  State  diagram  for  initial  BADD  call  .generator. 


•  INTT.  When  the  program  is  in  this  state  it  initializes  the  variables  local  to 
this  module.  Using  functions  provided  by  OPNET,  it  also  reads  the  model 
attributes  for  this  module.  The  model  attributes  include  the  mean  duration  of 
the  call,  the  mean  call  wait  time,  the  mean  interarrival  rate  and  the  mean  packet 
size.  These  attributes  define  the  type  of  calls  generated  by  this  module.  The 
use  of  each  of  these  variables  is  described  in  other  states  within  this  module. 

•  config.  From  the  INIT  state,  the  process  transitions  to  the  config  state  where 
it  first  broadcasts  the  IDS  LAN's  network  management  information,  such  as 
object  ID.  module  ID,  and  module  type,  to  a  corresponding  module  inside  all 
other  nodes.  Then  it  waits  to  receive  their  information.  The  waiting  is  shown  in 
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our  diagram  by  the  transition  labeled  default.  We  note  that  while  the  process 
is  in  this  state,  it  can  be  interrupted  by  the  simulation  kernel.  As  described  in 
Chapter  V,  this  is  called  an  unforced  state. 

•  schedule.  When  the  module  enters  this  state  it  generates  an  event,  in  the 
future,  at  which  time  the  next  request  will  be  generated.  The  time  of  the 
generated  event  is  controlled  by  the  mean  call  wait  time  distribution  read 
while  the  process  was  in  the  INIT  state. 

•  idle.  The  process  remains  in  the  idle  state,  an  unforced  state,  until  the  gen- 
erated request  time  arrives.  This  wait  time  was  determined  in  the  schedule 
state. 

•  start.  When  the  time  arrives  for  the  scheduled  call  to  occur,  this  process 
transitions  to  the  start  state.  The  module  initiates  the  call  by  creating  a  call 
descriptor  Interface  Control  Information  (Ici)  packet  and  forwarding  the 
Ici  to  the  remote  AAL  module.  The  Ici  is  an  OPNET  defined,  multi-member 
data  item  used  to  pass  control  information  between  different  modules  and 
processes.  The  Parameter  Editor,  as  described  in  Chapter  V,  can  be  used  to 
modify  the  Ici  format.  For  this  module,  we  used  the  predefined  Ici,  amsifici 
packet.  This  Ici  contains  the  call's  destination  address,  the  call's  AAL  type, 
the  call's  QOS  class,  and  the  call's  traffic  contract  requirements. 

•  EstCon.  The  module  waits  in  this  state  for  the  AAL  module  to  respond  to 
the  call  request.  If  the  AAL  module  responds  with  a  call  release  indication 
because  the  network  cannot  support  the  call  request,  this  module  drops  the 
call  request  and  transitions  back  to  the  schedule  state.  If  the  AAL  module 
responds  with  a  call  connection  signal,  the  module  generates  a  delayed  event 
that  signifies  the  end  of  the  call.  Rather  than  count  packets,  this  module 
generates  packets  until  the  end  of  the  call  event  arrives.  The  delay  time  for 
this  event  is  generated  using  the  mean  call  duration  described  earlier.  Finally, 
it  generates  an  event  corresponding  to  the  generation  of  the  first  data  packet 
which,  after  an  appropriate  wait  time,  causes  a  transition  to  the  data  gen 
state. 

•  data  gen.  While  in  this  state  the  process  generates  data  packets  and  forwards 
the  data  packets  to  the  AAL  module.  The  data  packets  are  generated  at  the  size 
and  rate  defined  by  the  model  attributes  mean  packet  size  and  mean  interarrival 
time,  respectively.  The  module  remains  in  this  state  until  the  end  of  the  call 
event  arrives  or  the  AAL  module  signals  a  release  of  the  data  channel.  If  the  call 
request  is  completed,  this  state  sends  a  call  release  signal  to  the  AAL  module 
and  transitions  to  the  RelCon  state.  If  the  AAL  module  sent  a  call  release 
signal,  meaning  the  network  dropped  the  channel,  this  state  stops  sending  data 
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packets  and  drops  the  call  request.  The  call  release  signal  causes  a  transition 
back  to  the  schedule  state  for  scheduling  the  next  call. 

•  RelCon.  When  in  this  state,  the  module  waits  for  the  AAL  module  to  signal 
a  Release  Confirm  acknowledgment,  meaning  the  ATM  network  completed  the 
transmission  of  all  data  packets  and  has  released  the  channel  resources.  Upon 
receiving  Release  Confirm,  this  module  transitions  back  to  the  schedule  state. 

b.         AAL  Module 

The  AAL  module  serves  as  the  interface  between  the  call -generator 
and  the  ATM  modules.  While  in  this  section  we  focus  our  descriptions  on  the  IDS 
LAN  node,  this  module  is  also  used  in  the  TACTICAL  LAN  node.  This  module 
coordinates  the  signaling  of  call  requests  from  the  call -generator  and  it  segments  the 
call  data  packets  into  48-byte  segments  for  transport  across  the  ATM  network.  The 
AAL  process  state  diagram  is  shown  in  Figure  32.  A  description  of  these  states  is 
given  below. 


Figure  32.  State  diagram  for  AAL  module. 


•  INIT.  This  state  is  used  to  initialize  numerous  variables  within  the  process 
model.  Additionally,  while  in  this  state,  the  module  creates  and  initializes 
memory  that  is  shared  with  all  dynamic  processes  spawned  by  this  module. 
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•  dispatch.  In  this  state,  the  module  distributes  appropriately  all  requests  re- 
ceived by  the  AAL  module.  The  distribution  is  controlled  by  the  type  of 
request  received  and  the  data  within  the  request. 

•  notify.  The  process  in  this  state  broadcasts  node  descriptor  information  to  all 
other  nodes  within  the  simulation  network. 

•  setup.  Upon  receipt  of  a  call  request  from  the  call -generator  or  the  network, 
this  state  is  used  to  spawn  a  dynamic  Signaling  AAL  (SAAL)  process  to 
handle  that  request.  It  then  passes  the  call  descriptor  Ici  to  the  newly  created 
process.  Because  the  SAAL  process  is  a  dynamic  process,  it  is  not  shown  in 
Figure  31.  (The  SAAL  process  is  described  later  in  this  section.) 

•  conn  irpt.  When  in  this  state  the  module  receives  and  processes  signals  per- 
taining to  individual  channel  connections.  Based  upon  the  type  of  signal  re- 
ceived, this  module  forwards  the  connection  signal  to  the  corresponding  SAAL 
for  processing.  This  module  then  transitions  back  to  the  dispatch  state. 

c.  ATMJayer  Module 

The  ATMJayer  module  is  the  first  of  the  four  ATM  modules  in  OPNET. 
(Together  these  four  ATM  modules  perform  all  of  the  functions  of  the  ATM  layer  as 
defined  in  chapter  II.)  This  module  is  used  in  all  nodes  throughout  the  network.  This 
module  is  responsible  for  coordinating  the  functions  of  the  other  three  ATM  modules. 
Primarily,  it  serves  as  an  interface  between  the  ATM  modules,  AAL  module,  and  the 
application  modules.  It  forwards  call  requests  to  the  ATM_mgmt  module  for  Virtual 
Path  Identifier  (VPI)  and  Virtual  Channel  Identifier  (VCI)  assignment.  It  forwards 
data  cells  to  the  ATMjswitch  module.  The  ATMJayer  process  state  diagram  is  shown 
in  Figure  33.  A  description  of  these  states  is  given  below. 

•  INIT.  When  in  this  state,  the  module  initializes  local  variables. 

•  config.  This  state's  functionality  is  identical  to  the  config  state  in  the  call  .generator 
module  on  page  70. 

•  wait.  This  state  waits  for  an  event  (reception  of:  a  call  request,  data  packets 
or  network  messages)  to  occur  and  uses  it  type  to  determine  the  next  state. 

•  AAL  int.  This  state  forwards  the  call  descriptor  Ici  to  the  ATM_mgmt  module 
when  a  call  request  is  received  from  the  AAL  module. 
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Figure  33.  State  diagram  for  ATM  Layer  module. 

•  MGMT  int.  This  state  forwards  call  descriptor  information,  indicating  the 
status  of  a  call  request,  to  the  AAL  module. 

•  from  AAL.  When  a  48-byte  data  segment  arrives  from  the  AAL  module,  this 
state  is  entered  and  the  module  adds  the  appropriate  cell  header,  inserts  the 
data  segment  into  the  cell  payload,  and  forwards  the  newly  created  ATM  cell 
to  the  ATMjswitch  module  for  transmission. 

•  from  mgmt.  A  process  in  this  state  forwards  an  ATM  management  cell  to 
the  ATMjswitch  module  for  transmission. 

•  to  AAL.  When  in  this  state,  the  module  processes  all  data  cells  addressed  to 
this  node.  After  removing  the  ATM  cell  header,  this  state  forwards  the  48-byte 
data  segment  to  the  AAL  module. 

d.  ATM _mgmt  Module 

The  ATMjmgmt  module  manages  the  Virtual  Paths  (VPs)  and  Virtual 
Channels  (VCs)  for  all  calls  associated  with  a  node.  This  module  is  used  in  all  nodes 
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throughout  the  network.  For  a  node  that  originates  calls,  this  module  sends  and  co- 
ordinates the  call  setup  and  connect  messaging.  For  an  intermediary  node  between  the 
source  and  destination,  this  node  assigns  a  VP  and  VC  and  then  forwards  the  setup 
message  on  to  the  next  node  enroute  to  the  destination.  For  a  destination  node,  the 
ATM_mgmt  module  forwards  a  call  request  to  the  ATM  Jayer  and  awaits  a  response 
from  the  ATM  Jayer  indicating  acceptance  or  rejection  of  the  call.  Based  on  the  ac- 
ceptance or  rejection,  this  module  then  sends  the  appropriate  message,  corresponding 
to  the  acceptance  or  rejection,  back  to  the  source  node.  The  ATM_mgmt  process  state 
diagram  is  shown  in  Figure  34.  A  description  of  these  states  is  given  below. 

(default) 


(«IL_XHTRPT) 


(  ARL_E  ST  AB_RE  Q  )_  -  - 


(default)     * 


Figure  34.  State  diagram  for  ATM  Mgmt  module. 

•  INIT,  config,  and  wait.  These  states  provide  the  same  functions  in  support 
of  this  network  module  as  the  identically  named  states  denned  in  ATM  Jayer 
module  on  page  73. 
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•  route  start.  In  this  state,  the  module  spawns  a  dynamic  process  to  execute 
dynamic  routing.  The  routing  process  creates  a  routing  table  from  this  node  to 
all  other  nodes  within  the  network.  (A  full  description  of  the  dynamic  routing 
process  is  given  later  in  this  section.) 

•  AAL  intrpt.  This  state  is  used  to  parse  the  AAL  interrupt  type. 

•  AAL  Estab.  When  a  call  request  arrives,  this  state  is  used  to  process  the  AAL 
establishment  request  from  the  AAL  module.  This  state  spawns  a  dynamic 
process  called  calLsrc  which  then  handles  this  call  request.  (A  full  description 
of  the  dynamic  calljsrc  process  is  given  later  in  this  section.) 

•  AAL  other.  This  state  handles  other  AAL  module  requests  for  this  node  by 
forwarding  it  to  the  appropriate  dynamic  call_src  process  (which  was  previously 
created  in  an  AAL  Estab  state  that  corresponds  to  this  request). 

•  control  cell.  After  receiving  a  control  cell  from  the  network,  this  state  is  used 
to  determine  the  type  of  control  cell. 

•  ATM  setup.  For  a  call  establishment  request,  this  state  is  entered  and  the 
module  checks  the  destination  of  the  call.  If  this  node  is  the  destination,  this 
state  is  used  to  spawn  a  dynamic  process,  calLdst,  which  then  handles  this 
call  request.  If  this  is  not  the  destination  node,  this  state  spawns  a  dynamic 
process  called  call_net  which  forwards  the  call  request  on  to  the  next  node.  (A 
full  description  of  the  dynamic  calLdst  and  call_net  processes  are  given  later 
in  this  section.) 

•  ATM  signal  other.  In  this  state,  the  module  handles  other  ATM  control  cells 
sent  to  this  node.  If  a  dynamic  call_net  or  calLdst  already  exists  to  handle  the 
request,  this  state  forwards  it  to  the  appropriate  process.  If  the  signal  is  a 
network  call  release  request,  this  state  is  used  to  forward  the  release  request 
to  the  next  node  enroute  to  the  destination  address. 


• 


routing  cell.   For  dynamic  routing  cells,  a  module  in  this  state  forwards  the 
routing  message  to  the  dynamic  routing  process  for  this  module. 


e.  ATM -trans  Module 

The  ATM_trans  module  handles  all  cells  received  from  the  ATM  net- 
work. This  module  is  used  in  all  nodes  throughout  the  network.  It  first  determines  the 
type  of  an  ATM  cell:  control  or  data.  It  forwards  the  control  cells  to  the  ATM_mgmt 
module.  For  data  cells,  this  module  determines  whether  the  data  cell  is  destined  for 
this  node.    If  the  data  cells  is  destined  for  this  node,  the  module  forwards  it  to  the 
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ATM  Jay  er  module,  otherwise  this  module  forwards  the  data  cell  to  the  ATM_switch 
module.  The  ATM_trans  process  state  diagram  is  shown  in  Figure  35.  A  description 
of  these  states  is  given  below. 


(default) 


Figure  35.  State  diagram  for  ATM_trans  module. 

•  INIT,  config,  and  wait.  These  states  provide  the  same  functions  in  support 
of  this  network  module  as  the  identical  states  defined  in  ATM  Jayer  module  on 
page  73. 

•  ATM  cell.  This  state  determines  the  type  of  ATM  cell  that  arrived  from 
another  node  in  the  network. 

•  control  cell.  This  module  transitions  to  this  state  when  a  control  cell  arrives. 
It  forwards  the  control  cell  to  the  ATM_mgmt  module. 

•  data  cell.  This  state  is  reached  upon  reception  of  a  data  cell.  This  module 
delivers  the  data  cells  addressed  to  this  node  to  the  ATMJayer  module.  (For 
data  cells  addressed  to  other  nodes  in  the  network,  this  module  delivers  the 
data  cell  to  the  ATM_switch  module.) 

/.  ATM-switch  Module 

This  module  forwards  ATM  cells  to  the  next  node  in  the  ATM  network. 
This  module  is  used  in  all  nodes  throughout  the  network.  The  ATMjswitch  process 
state  diagram  is  shown  in  Figure  36.  A  description  of  these  states  is  given  below: 
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Figure  36.  State  diagram  for  ATMjswitch  module. 

•  INIT,  config,  and  wait.  These  states  provide  the  same  functions  in  support 
of  this  network  module  as  the  identical  states  defined  in  ATM  Jayer  module  on 
page  73. 

•  cell  arrival.  In  this  state,  the  module  processes  new  ATM  cells  as  they  arrive. 
It  places  all  cells  in  a  queue  for  transmittal.  All  cells  are  held  in  this  queue  for 
an  amount  of  time  based  on  the  switching  fabric. 

•  cell  transmit.  In  this  state,  the  module  dequeues  the  next  ATM  cell  and 
sends  it  to  the  next  node  in  the  network,  using  a  direction  that  is  based  on  the 
addressing  information  contained  within  the  cell. 

2.        IDS  LAN  Dynamic  Processes 

This  section  describes  the  dynamic  processes  required  to  support  the  function- 
ality of  the  modules  within  the  IDS  LAN  node. 

a.         SAAL  Process 

The  SAAL  process  is  a  dynamic  process  created  by  the  AAL  module 
to  handle  the  signaling  for  a  call  request.  It  exists  in  multiple  instantiations  in  the 
IDS  LAN  and  the  TACTICAL  LAN,  to  support  concurrent  calls  in  our  simulation. 
Each  SAAL  process  corresponds  with  a  peer  SAAL  process  at  the  destination  node 
to  process  the  call  request.  The  process  state  diagram  is  shown  in  Figure  37.  A 
description  of  these  states  is  given  below. 
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Figure  37.  State  diagram  for  SAAL  process. 

•  INIT.  In  addition  to  code  initializing  the  process's  variables,  this  state's  code 
determines  the  type  of  request  for  which  it  was  spawned. 

•  EReq.  This  state  is  used  to  forward  the  call  requests  from  the  application 
module  to  the  ATMJayer  module.  The  process  remains  in  this  state  awaiting 
a  response.  If  the  ATMJayer  responds  with  a  call  release  message,  this  state's 
code  sends  the  application  module  a  message  canceling  the  call  request  and 
then  terminates  this  SAAL  process.  If  the  ATMJayer  responds  with  a  call 
connection  message,  this  state  spawns  a  dynamic  process  called  AAL5_Conn 
and  then  invokes  the  process  to  handle  the  AAL5  functions  for  this  call. 

•  ECon.  This  is  used  to  wait  for  the  network  to  acknowledge  the  request  to 
establish  the  connection. 
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•  BGAK.  When  the  network  accepts  a  request  by  sending  an  acknowledgment, 
the  process  in  this  state  sends  a  message  to  the  application  module  to  start 
sending  data  packets.  If  the  network  rejects  the  request,  then  it  sends  the 
application  module  a  message  canceling  the  call  request  and  then  terminates 
this  SAAL  process. 

•  connect.  After  establishing  the  connection,  the  process  waits  in  this  state  until 
either  the  call  completes  or  the  network  abnormally  terminates  the  call. 

•  END.  When  a  call  successfully  completes,  the  SAAL  process  in  this  state  sends 
an  END  request  to  its  peer  SAAL  process. 

•  Rind.  After  sending  an  END  request  to  its  peer,  the  process  enters  the  Rind, 
where  it  awaits  the  response  from  the  network,  acknowledging  the  END  re- 
quest. The  acknowledgment  indicates  the  network  has  freed  all  resources  as- 
sociated with  the  call  request. 

•  kill.  The  process  in  this  state  destroys  the  dynamic  AAL5_conn  process  and 
this  SAAL  process. 

•  EInd.  The  SAAL  process,  at  the  destination  node,  enters  this  state  when  the 
call  request  is  delivered  from  the  ATMJayer  module.  In  this  state  the  process 
handles  the  request  by  forwarding  the  request  to  the  application  module.  The 
process  also  creates  a  dynamic  AAL5_conn  process  to  handle  the  call  request. 

•  BG.  The  SAAL  process  waits  in  this  state  for  a  response  from  the  application 
module.  If  the  application  module  accepts  the  call  request,  the  code  in  this 
state  generates  an  acknowledgment  for  the  call  source  node.  If  the  applica- 
tion module  rejects  the  request,  the  process  destroys  the  dynamic  AAL5_conn 
process  and  this  SAAL  process. 

•  no  BGAK,  irreg  kill,  send  END,  no  ENDAK,  ENDAK,  and  RREQ. 

The  SAAL  process  in  these  states  handles  those  instances  when  the  network 
sends  a  negative  acknowledgment  to  a  request  or  fails  to  send  any  type  of 
acknowledgment. 

b.         A AL 5 -Conn  Process 

The  SAAL  process  creates  and  invokes  an  AAL5_conn  process  to  handle 
packet  segmentation  and  packet  reassembly  functions.  When  spawned  by  a  sender, 
this  process  breaks  data  packets  received  from  the  application  layer  into  48-byte  seg- 
ments and  forwards  the  segments  to  the  ATMJayer  module.  When  spawned  by  the 
receiver,  it  reassembles  the  48-byte  data  segments  from  the  ATMJayer  module  into 
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a  data  packets.    The  process  state  diagram  is  shown  in  Figure  38.    A  description  of 
these  states  is  given  below. 


(TO_ATM_DATA    | |    SSC0P_PDU) 


(release) 


(FROM_ATM_DATA) 


Figure  38.  State  diagram  for  AAL5  Connection  process. 


•  setup.  When  in  this  state,  the  process  initializes  local  variables  and  creates 
the  buffers  used  for  segmentation  and  reassembly. 

•  data.  When  data  arrives,  the  process  enters  this  state  and  determines  the 
type  and  source  of  the  data.  For  call  requests  and  call  data  packets  from 
the  application  module,  the  process  transitions  to  the  to_atm  state.  For  data 
segments  from  the  ATMJayer  module,  it  transitions  to  the  from_atm  state. 

•  to_atm.  In  this  state,  the  AAL5_conn  process  decomposes  messages  into  48- 
byte  segments  and  sends  the  segments  to  the  ATM  Jayer  module. 

•  fr.atm.  When  the  process  enters  this  state,  it  reassembles  the  data  segments 
into  a  data  packet  and  forwards  the  packet  to  the  application  module. 

•  release.  In  this  state  the  process  decomposes  a  call  completion  message  from 
the  application  layer  into  48-byte  segments  and  sends  the  segments  to  the 
ATMJayer  module. 

•  data  rel.  After  starting  the  connection  release  process,  no  more  data  packets 
can  be  sent  but  additional  data  segments  are  still  accepted  from  the  ATMJayer. 
This  process  transitions  to  the  to_atm_rel  state  when  call  data  packets  arrive 
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and  transitions  to  the  from_atm  state  when  data  segments  from  the  ATM  Jayer 
module  arrive. 

•  to_atm_rel.  This  state  is  used  to  destroy  all  application  data  packets  received 
after  sending  the  connection  release  message. 

•  from_atm_rel.  In  this  state,  the  process  continues  to  accept  additional  ATM 
data  segments  until  the  connection  terminates. 

•  end.  This  state  is  used  to  destroy  the  AAL5_conn  process. 

c.         Routing  Process 

The  ATM_mgmt  process  creates  and  invokes  a  routing  process  to  handle 
call  routing  for  the  ATM  node.  This  process  constructs  and  maintains  the  dynamic 
routing  table.  The  routing  table  uses  an  adaptation  of  the  Bellman-Ford  Shortest 
Path  algorithm  [Ref.  16,  4].  The  process  state  diagram  is  shown  in  Figure  39.  A 
description  of  these  states  is  given  below. 


Figure  39.  State  diagram  for  Dynamic  Routing  process. 


•  INIT.  The  code  in  this  state  initializes  the  local  variables  and  creates  an  empty 
routing  table. 
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UPDATE.  Periodically,  the  routing  table  is  checked  for  accuracy.  In  this 
state,  the  routing  process  removes  any  old  links  from  the  routing  table  and 
recalculates  the  cost  for  all  current  routes.  The  code  in  this  state  also  broadcast 
the  address  resolution  packets  (ARP)  to  all  neighboring  nodes.  The  ARP 
ensures  that  all  neighbors  maintain  active  routes  containing  information  about 
the  current  node. 

WAIT.  When  in  this  state,  the  process  waits  for  an  event  to  occur. 

ARP.  The  process  transitions  to  this  state  when  address  resolution  packets 
arrive.  These  packets  are  used  to  verify  and  update  the  routing  table  as  neces- 
sary. 

•  ADVERT.  The  process  transitions  to  this  state  when  route  advertisement 
packets  arrive.  The  process  verifies  that  the  route  contained  in  the  route  ad- 
vertisement packet  is  valid  and  that  the  route  does  not  cause  a  loop  in  the 
network.  The  process  then  updates,  using  the  new  route,  the  cost  of  all  routes 
in  the  routing  table. 

•  QUERY.  When  in  this  state,  another  process  has  requested  the  shortest  route 
to  a  particular  destination  node.  The  code  in  this  state  searches  the  routing 
table  to  determine  the  best  route  available  and  verifies  that  the  route  is  still 
available.  It  returns  the  output  port  number  for  the  best  route  to  the  destination 
node. 

•  FAILURE.  Because  a  link  failed  in  the  network,  this  process  must  update  the 
routing  table  by  removing  the  link  and  calculating  a  new  cost  for  routes  previ- 
ously using  the  failed  link.  Additionally,  the  code  within  this  state  broadcasts 
a  route  advertisement  packet  to  all  neighboring  nodes  notifying  them  of  the 
new  cost  of  all  routes  through  the  current  node. 

•  RECOVERY.  During  a  simulation,  nodes  may  be  programmed  to  temporar- 
ily fail  and  then  recover  from  the  failure.  When  failure  occurs,  OPNET  issues  a 
recovery  interrupt.  The  process  transitions  to  this  state  to  handle  the  recovery 
interrupt  and  it  then  transitions  to  the  UPDATE  state. 

d.  CalLSrc  Process 

The  ATM_mgmt  process,  at  the  calling  node,  creates  and  invokes  a 
calljsrc  process  for  each  VCC  to  handle  ATM  signaling  (VCC  setup  and  release). 
This  process  is  then  destroyed  at  connection  termination.  The  process  state  diagram 
is  shown  in  Figure  40.  A  description  of  these  states  is  given  below. 
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Figure  40.  State  diagram  for  CalLSrc  process. 


•  INIT.  This  state  is  responsible  for  initializing  numerous  variables  within  the 
process  model.  Additionally,  this  state  obtains  the  call  description  from  the 
ATM_mgmt  module. 

•  Call  Route.  Code  in  this  state  determines  whether  a  route  exists  from  the 
source  node  to  the  destination  node  and  ensures  sufficient  bandwidth  is  avail- 
able on  the  route.  This  state  invokes  the  dynamic  routing  process  created  by 
the  ATM_mgmt  module. 

•  Call  Initiated.  Here  the  module  sends  a  setup  message  to  the  next  node 
enroute  to  the  destination  node.    The  process  then  waits  in  this  state  for  a 
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response  from  the  network.  The  network  may  accept  the  call,  reject  the  call, 
or  not  respond  at  all. 

•  call  alloc.  When  the  network  responds  with  a  call  accept  or  call  proceeding 
message,  this  state's  code  allocates  resources  at  the  source  node  to  support  the 
call  request. 

•  Outgoing  Call  Proceeding.  Code  in  this  state  waits  for  the  connection 
request  to  propagate  through  the  network. 

•  Active.  This  state  is  reached  when  a  'connect'  message  is  received  from  the 
network,  meaning  that  the  connection  is  available  for  data  transmission.  It 
then  sends  the  'connect  ack'  message  to  the  first  intermediate  node. 

•  Release  Request.  When  in  this  state,  the  module  handles  the  release  connec- 
tion request  by  first  sending  the  'release  connection'  message  to  the  network. 
After  the  network  releases  the  connection,  it  sends  a  'release  confirm'  message 
to  the  AAL  module. 

•  NULL.  Code  in  this  state  is  responsible  for  releasing  the  connection  resources 
at  the  source  node  and  destroying  this  calljsrc  process. 

•  reject  call,  release  cmpl,  and  release  indication.  These  remaining  states 
handle  those  instances  when  the  network  rejects  a  connection  request  or  simply 
fails  to  respond  to  a  connection  request. 

e.  Call-Net  Process 

The  ATM_mgmt  process,  at  each  intermediate  node,  creates  and  invokes 
a  call_net  process  for  each  VCC  to  handle  ATM  signaling  (VCC  setup  and  release). 
This  process  is  destroyed  at  connection  termination.  The  process  state  diagram  is 
shown  in  Figure  41.  A  description  of  these  states  is  given  below. 

•  INIT.  In  the  INIT  state  numerous  variables  within  the  process  model  are 
initialized.  Additionally,  this  state  determines  whether  the  connection  request 
previously  passed  through  this  node. 

•  No  Fwd  Call.  If  this  state  is  reached  we  know  that  the  connection  request 
previously  passed  through  this  node,  and  consequently  the  code  destroys  both 
the  request  and  this  process. 

•  Call  Initiated.  Here  the  module  determines  whether  a  VP  and  a  VC  are 
available  to  support  the  connection. 
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Figure  41.  State  diagram  for  CalLNet  process. 
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•  release  cmpl.  When  resources  are  not  available  to  support  the  connection 
request,  this  state  is  used  to  send  a  connection  rejection  message  to  the  source 
node  after  which  it  destroys  this  process. 

•  Outgoing  Call  Proceeding.  When  resources  are  available  to  support  the 
connection  request,  this  state  is  used  to  assign  resources  to  the  connection. 

•  Call  Present.  This  state  is  used  to  send  a  setup  message  to  the  next  node 
enroute  to  the  destination  node.  The  process  then  waits  for  a  network  response. 
The  network  may  accept  the  connection,  reject  the  connection,  or  not  respond 
at  all. 

•  Connect  Request.  When  the  network  accepts  the  connection,  this  state  is 
used  to  forward  the  acceptance  towards  the  source.  The  module  also  sends  a 
connection  acknowledgment  to  the  previous  node. 

•  Active.  Reaching  this  state  means  that  the  connection  is  available  for  data 
transmission.  The  process  then  remains  in  this  state  awaiting  a  signal  to  release 
the  connection. 

•  Release  Indication.  When  this  state  is  reached,  the  network  has  rejected  the 
call  or  failed  to  respond  to  the  connection  request.  The  process  then  sends  a 
call  release  message  to  all  the  other  nodes  within  the  network. 

•  call  clear  and  call  clear  cont.  These  states  are  used  to  free  resources 
allocated  to  a  connection  and  to  send  a  release  message  to  other  nodes  within 
the  network. 

•  NULL.  This  state  destroys  this  callmet  process. 

/.  CalLDst  Process 

The  ATM_mgmt  process,  at  the  destination  node,  creates  and  invokes 
a  call_net  process  for  each  VCC  to  handle  ATM  signaling  (VCC  setup  and  release). 
This  process  is  destroyed  at  connection  termination.  The  process  state  diagram  is 
shown  in  Figure  42.  A  description  of  these  states  is  given  below. 

•  INIT.  This  state  is  used  to  initialize  numerous  variables  within  the  process 
model. 

•  Call  Init.  After  the  arrival  of  a  connection  request,  a  process  in  this  state 
determines  whether  resources  are  available  to  support  the  call. 
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Figure  42.  State  diagram  for  CallJDst  process. 
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•  Call  Present.  When  resources  are  available  this  state  is  used  to  allocate  the 
necessary  resources  and  send  the  call  request  to  the  AAL  module  at  the  des- 
tination node.  Additionally,  it  sends  a  call  proceeding  message  to  the  previous 
intermediate  node  in  the  network. 

•  Connect.  If  the  AAL  accepts  the  call  request,  this  state  is  used  to  send  the 
connect  message  to  the  intermediate  node  in  the  network. 

•  Active.  This  state  is  reached  when  the  connection  is  available  for  data  trans- 
mission. The  process  waits  in  this  state  for  the  AAL  module  to  signal  call 
completion  or  for  the  network  to  drop  the  connection.  If  the  AAL  module 
signals  call  completion,  the  next  state  is  the  Release  Request  state.  If  the 
network  dropped  the  connection,  the  transition  is  to  the  Release  Indication 
state. 

•  Release  Request.  This  state  is  used  to  send  a  release  connection  message  to 
other  nodes  in  the  network  and  waits  for  a  response  from  the  network. 

•  Release  Indication.  A  process  in  this  state  sends  a  release  acknowledgment 
message  to  the  previous  node  in  the  network. 

•  call  rejected.  This  state  is  used  to  send  the  connection  rejection  message  to 
other  nodes  in  the  network. 

•  NULL.  This  state  is  used  to  return  resources  that  were  allocated  to  the  con- 
nection and  to  destroy  the  calLdst  process. 

3.       Uplink  LDR  and  Dnlink  LDR 

For  our  network,  we  chose  to  represent  the  Uplink  LDR  and  Dnlink  LDR  as 
simple  ATM  switches.  Figure  43  shows  the  node  diagram  for  our  LDR  switch.  This 
node  contains  the  four  ATM  modules  that  we  discussed  in  the  previous  section.  Unlike 
the  IDS  LAN  these  nodes  support  three  communication  links  rather  than  one.  The 
three  transceiver  links  are  represented  by  the  following  modules:  (pr_0,  pt_0),  (pr_l, 
pt_l),  and  (pr_2,pt_2).  Two  of  these  links  support  a  transmission  channel  capacity 
of  155  Mbps.  The  third  supports  only  an  8  Mbps  channel  capacity.  The  low  data 
rate  channel  represents  the  BADD  ATM  channel  capacity  available  through  the  GBS 
system. 
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Figure  43.  Uplink  and  Dnlink  Low  Data  Rate  switch  node  diagram. 

4.        Tactical  LAN  Subnetwork 

The  Tactical  LAN  subnet  in  our  model  contains  a  single  WFA  switch  and  the 
traffic  destination  as  shown  in  Figure  44.  Our  model  is  extensible  in  that  it  would 
require  very  little  modification  to  add  additional  WFA  switches  and  traffic  destination 
modules. 
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Figure  44.  Tactical  LAN  Subnetwork  diagram. 

a.  WFA  Switch 

The  WFA  switch  is  similar  to  the  Uplink  LDR  switch  shown  in  Fig- 
ure 43.  It  contains  the  four  ATM  modules  and  two  transceivers,  both  with  a  channel 
capacity  of  155  Mbps. 
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b.  Traffic  Destination 

The  traffic  destination  node  is  similar  to  our  traffic  source  in  Figure  30. 
The  only  difference  is  that  the  call-generator  has  been  replaced  with  a  traffic  sink.  As 
data  segments  arrive  at  the  destination  node  they  are  reassembled  by  the  AAL  module 
and  forwarded  to  the  traffic  sink.  The  traffic  sink  updates  requested  statistics  and 
then  destroys  the  data  packet. 

5.  Network  Communication  Links 

After  defining  the  nodes  within  the  network,  we  connected  the  nodes  by  using 
OPNET  communication  links.  As  mentioned  earlier  in  this  section,  OPNET  currently 
does  not  support  simplex  ATM  channels,  therefore  we  first  inserted  the  standard 
OPNET  duplex  communication  links,  then  modified  the  code. 

Our  model  utilizes  two  types  of  communication  links:  one  with  a  capacity  of 
155  Mbps  and  the  other  with  a  capacity  of  8  Mbps.  The  standard  communication  link 
with  155  Mbps  capacity  connects  the  traffic  source  with  the  Uplink  LDR,  the  Dnlink 
LDR  with  the  WFA  switch,  and  the  WFA  switch  with  the  traffic  destination.  We 
modeled  this  link  after  a  standard  fiber  optic  connection  with  no  errors  and  no  delay. 

For  the  backbone  connection  between  the  Uplink  LDR  and  the  Dnlink  LDR,  we 
created  a  link  with  a  capacity  of  8  Mbps  using  the  OPNET  parameter  editor  described 
in  Chapter  V.  Initially,  we  defined  the  communication  link  with  a  transmission  delay 
of  0.25  seconds  which  is  a  typical  delay  time  for  a  single  geosynchronous  satellite 
transmission. 

6.  Modification  of  Our  Initial  OPNET  Modeler 

After  constructing  our  initial  OPNET  model,  we  began  testing  to  verify  that 
the  network  was  being  correctly  simulated.  When  we  ran  simulations  with  the  link 
delay  set  to  0.25  seconds,  the  simulation  terminated  abnormally  giving  the  error 
message  'traffic.dest  received  process  handle  for  destroyed  process.'  Tracing  the 
code,  we  found  a  simulation  timer  called  AMSC_AAL_TIMER_CC_DURATION  in 
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the  ams_aal_interfaces.h  file.  This  timer  defines  the  maximum  amount  of  time,  in 
seconds,  that  an  AAL  process  can  wait  for  a  response  to  the  connection  request  mes- 
sage. This  variable  was  originally  defined  as  0.25  seconds;  we  changed  the  timer  to 
10.0  seconds  and  the  simulation  ran  successfully. 

Another  problem  that  we  encountered  in  the  testing  of  our  basic  network  model 
was  the  calculation  of  Peak  Cell  Rate  (PCR)  for  small  calls.  When  the  packet  size 
is  less  than  384  bits,  OPNET  calculates  the  PCR  to  be  0.  Again,  tracing  the  code  we 
found  the  problem  to  be  integer  division.  We  modified  the  OPNET  code  to  explicitly 
cast  the  calculation  as  a  float,  which  yields  a  correct  PCR. 

C.      STATIC  CHANNELS  WITHIN  BADD  ATM  NETWORK 

The  next  phase  of  our  network  design  required  the  definition  of  static  channels 
within  the  BADD  ATM  network.  Chapter  II  describes  the  call  setup  protocol  for 
virtual  channel  definition  within  ATM.  Normally  virtual  channels  are  created  and 
destroyed  dynamically  by  the  network.  Because  the  GBS  backbone  within  BADD 
only  allows  simplex  communication,  BADD's  designers  chose  to  define  static  channels 
for  the  Uplink  LDR  and  Dnlink  LDR  during  network  configuration. 

To  simulate  this  configuration,  we  modified  our  network  in  two  phases.  In  the 
first  phase  we  defined  static  channels  at  each  ATM  switch  within  the  network  and  in 
the  second  phase  we  modified  the  network  to  use  the  static  channels. 

For  phase  one,  we  modified  the  ATMjngmt  module,  described  on  page  74,  by 
adding  a  state  called  static_channels_setup.  The  new  ATM_mgmt  module  is  shown 
in  Figure  45. 

The  code  for  the  newly  added  static.channelsjsetup  state  begins  by  opening  the 
input  .channels  file  and  reading  the  first  line.  The  first  line  contains  a  single  integer 
value  defining  the  number  of  static  channels  for  the  network.  The  maximum  allowable 
channels  are  1024  [Ref.  10].  Each  subsequent  line  in  the  input  .channels  file  defines 
a  single  channel  by  giving  its  bandwidth  capabilities.  This  state  is  then  used  to  add 
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Figure  45.  State  diagram  for  BADD  ATM  Mgmt  module. 

the  static  channels  to  each  ATM  path  and  allocate  the  bandwidth  to  the  channels  as 
defined  in  the  input  .channels  file. 

The  second  phase  requires  the  modification  of  the  calljsrc,  call  met  and  calLdst 
modules.  Each  of  these  modules  called  functions  for  creating  and  destroying  virtual 
channels  as  described  on  pages  83  through  87.  We  created  new  functions  for  alloc- 
ating only  the  static  channels  and  deallocating  the  channels.  In  the  calljsrc  module, 
we  modified  the  states  call  route,  release  cmpl,  call  alloc,  release  indication, 
and  NULL  to  call  our  new  functions.  In  the  callmet  module,  we  similarly  modi- 
fied the  states  call  initiated,  outgoing  call  processing,  and  call  clear  to  invoke 
our  new  functions.  Similarly,  in  the  calLdst  module,  we  modified  the  code  for  the 
states  Call  Init.  Call  Present,  and  NULL.  Appendix  B  contains  the  code  for  these 
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modifications. 

Although  the  simulation  ran  successfully,  link  utilization  was  extremely  low  as 
shown  in  Figure  46.  We  found  that  the  network  spent  the  majority  of  time  sending 
ATM  control  data  to  setup  and  tear  down  a  connection.  Although  this  overhead  is 
typical  for  duplex,  dynamic  channels,  it  should  be  absent  in  simplex,  static  virtual 
channels. 

According  to  OPNET  Communication  Mechanisms,  any  delay  defined  on  a 
communication  link  is  applied  equally  to  all  data  traversing  the  link  [Ref.  4].  This 
means  that  all  ATM  cells,  including  both  data  and  control  cells,  traversing  the  GBS 
backbone  are  delayed  for  0.25  seconds.  This  application  of  delay  is  not  appropriate 
for  the  BADD  network  because  the  link  is  simplex  with  static  virtual  channels.  Static 
channels  on  the  satellite  link  are  defined  at  the  switches  and  there  is  no  need  for 
signaling.  In  addition,  since  the  satellite  link  is  simplex  there  is  no  signaling  coming 
back  from  the  downlink  to  the  uplink.  Since  we  were  using  the  OPNET  duplex 
implementation  as  a  baseline,  we  resolved  these  conflicts  by  setting  the  communication 
link  delay  to  0.0  seconds  and  rewriting  the  ATM_switch  module  to  send  only  data  cells 
with  a  0.25  second  delay  over  the  GBS  backbone.  This  modification  triples  the  link 
utilization  as  illustrated  in  Figure  47. 

D.      FINAL  BADD  TRAFFIC  SOURCE 

In  the  initial  design  we  described  only  a  single  call  generator.  In  this  section 
we  describe  our  experiences  when  adding  additional  call  generators.  As  we  increased 
the  number  of  call  generators  we  observed  that  calls  were  being  dropped.  ATM  nor- 
mally drops  call  requests  when  sufficient  resources  are  unavailable  to  handle  the  call 
requested.  When  a  rejection  was  sent  to  our  call  generator,  it  would  respond  by  im- 
mediately issuing  another  request.  This  looping  process  lead  to  a  dramatic  increase 
in  the  number  of  call  requests  and  call  rejections.  This  problem  lead  us  to  redesign 
our  traffic  source  node  as  depicted  in  Figure  48.   This  section  describes  the  function 
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Figure  46.  Initial  link  utilization  for  our  basic  BADD  network. 
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Figure  47.  Link  utilization  after  modification  of  our  basic  BADD  network. 
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of  our  modified  call_requester  module,  our  new  call  .scheduler  module,  and  our  new 
dynamic  process  called  call  .generator. 


receiver 


transmitter 


Figure  48.  Node  Diagram  for  our  new  BADD  Traffic  Source. 

1.       BADD  Call  Requester 

OPNET's  call-generator  module  generates  a  single  call,  waiting  until  the  com- 
pletion of  the  previous  call  before  starting  the  next  call.  When  we  began  queuing  calls 
to  await  resources,  the  calLgenerator  process  would  not  generate  another  call  until  the 
call  had  been  removed  from  the  queue  and  processed.  This  wait  time  does  not  repres- 
ent a  realistic  scenario,  i.e.,  a  database  server  does  not  wait  for  an  acknowledgment 
indicating  that  its  last  response  was  sent  to  the  final  destination  before  processing  the 
next  query.  To  correct  this  problem,  we  divided  the  call  generation  process  into  two 
distinct  processes:  call  request  generation  and  data  generation. 
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Figure  49  shows  our  new  call_requester  module.  This  process  iteratively  gen- 
erates a  call  request  and  then,  using  the  input  mean  interarrival  rate,  generates  the 
event  for  the  time  to  generate  the  next  call  and  continues  processing  regardless  of  the 
status  of  the  requested  call.  A  description  of  the  call_requester  states  is  given  below. 


(default) 


\     (WAIT_CW.L_BUMTIOH> 


Figure  49.  State  diagram  for  BADD  calljrequester  module. 


•  INIT,  config,  schedule,  and  wait.  These  states  provide  the  same  functions 
in  support  of  this  network  module  as  the  identical  states  defined  in  our  initial 
call  .generator  module  on  page  70. 

•  start.  When  the  module  enters  this  state,  it  creates  a  badd_call_reqjf  Jci  packet 
describing  the  call.  The  module  attributes  read  during  the  INIT  state  are 
copied  into  the  Ici  packet  before  it  passes  the  call  request  to  the  call  .scheduler 
module.  Lastly,  this  module  generates  an  event,  in  the  future,  at  which  time 
the  module  will  schedule  the  next  call  request. 

•  wait_call_duration.  The  module  remains  in  the  wait_call_duration  state 
until  the  time  for  the  event  generated  in  the  previous  start  state  arrives.  The 
module  then  transitions  back  to  the  schedule  state. 
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2.        BADD  Call  Scheduler 

The  call-jscheduler  module  accepts  call  requests  and  schedules  the  calls  for 
transmission  over  the  static  channels.  The  state  diagram  for  our  new  call_scheduler 
module  is  shown  in  Figure  50.  A  description  of  the  calljscheduler  states  is  given  below: 

•  INIT.  In  this  state,  the  module  initializes  local  variables  and  reads  the  model 
attribute  variables.  The  model  attributes,  calls  pending  and  scheduler  delay, 
define  the  maximum  number  of  call  requests  that  will  be  allowed  to  be  enqueued 
before  they  are  assigned  a  time  and  virtual  channel.  The  scheduler  delay  is  the 
maximum  time  that  any  request  can  remain  in  the  queue  before  it  is  assigned 
a  time  and  channel.  While  in  this  state,  the  module  also  creates  the  global  wait 
queue  and  the  individual  static  channel  queues. 

•  config.  This  state  provides  the  same  functions  in  support  of  this  network 
module  as  the  identical  state  defined  in  our  initial  calLgenerator  module  on 
page  70. 

•  shared  data.  The  module  transitions  to  this  state  after  neighbor  notification, 
discussed  at  page  70  ,  is  completed.  The  code  in  this  state  initializes  variables 
shared  by  all  the  processes  within  the  call_scheduler  module.  The  call_scheduler 
will  later  spawn  a  dynamic  call-generator  process  which  will  access  these  shared 
variables  to  determine  the  current  ATM  network  configuration. 

•  dispatch.  The  code  in  this  state  functions  as  a  task  dispatcher,  starting  tasks 
based  on  the  type  of  interrupt  received. 

•  call  request.  Upon  the  arrival  of  a  call  request,  this  module  transitions 
from  the  dispatch  state  to  the  call  request  state  where  it  inserts  the  call 
request  into  the  calls  .pending  list.  The  calls  .pending  list  contains  all  of  the 
calls  that  require  scheduling.  After  adding  the  call  to  the  calls_pending  list, 
control  returns  to  the  dispatch  state. 

•  call  schedule.  If  the  number  of  calls  in  the  calls.pending  list  exceeds  the 
calls_pending  attribute,  or  the  scheduler  delay  attribute  timer  expires,  then 
the  module  transitions  from  the  dispatch  state  to  the  call  schedule  state. 
Upon  entering  the  call  schedule  state,  the  code  schedules  all  of  the  calls  in 
the  calls_pending  list  by  assigning  each  call  to  a  static  channel  according  to 
one  of  the  scheduling  algorithms  described  in  chapter  IV.  As  calls  are  added 
to  a  static  channel,  the  call  is  time-stamped  with  the  time  it  was  enqueued. 
When  calls  are  scheduled  on  an  idle  channel,  the  module  generates  a  call_start 
signaling  event  that  starts  the  first  call  on  the  idle  channel.  After  scheduling 
all  available  calls,  the  module  transitions  back  to  the  dispatch  state. 
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Figure  50.  State  diagram  for  BADD  calljscheduler  process. 
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•  start  call.  When  the  calljstart  event  arrives,  the  module  transitions  to  this 
state.  The  module  dequeues  the  first  call  for  the  channel  and  spawns  a  dynamic 
call -generator  process  and  assigns  that  process  to  handle  this  call.  It  then 
transitions  back  to  the  dispatch  state.  (The  description  for  calLgenerator 
process  follows  in  the  next  subsection.) 

•  send  data.  Because  all  signals  for  a  dynamic  calLgenerator  process  are  re- 
turned to  the  parent  call_scheduler  module,  there  must  exist  a  mechanism 
whereby  it  can  identify  which  calLgenerator  to  invoke.  OPNET  uses  a  process 
pointer,  called  prohandle,  to  uniquely  identify  each  dynamic  process.  All 
signals  returned  to  the  call_scheduler  contain  the  prohandle  for  the  required 
calLgenerator.  Since  the  calLgenerator  process  invoked  in  the  call  start  sends 
a  call  connection  request  to  the  AAL  module,  the  AAL  module  signals  the 
calljscheduler  when  the  connection  is  established.  This  signal  forces  a  trans- 
ition from  the  dispatch  state  to  the  state  send  data  state.  This  module  awakes 
the  sleeping  calLgenerator  process  and  signals  the  call  .generator  to  start  send- 
ing data  on  the  established  connection.  After  invoking  the  call-generator,  the 
module  again  transitions  to  the  dispatch  state. 

•  call  complete.  The  calLgenerator  continues  to  send  data  until  the  call  com- 
pletes transmission.  The  calLgenerator  then  signals  the  AAL  module  to  release 
and  close  the  connection.  The  AAL  module  again  signals  the  calljscheduler 
after  releasing  the  connection.  This  release  connection  signal  forces  a  trans- 
ition to  the  call  complete  state.  Upon  entering  this  state,  the  module  invokes 
the  requested  calLgenerator  and  signals  the  calLgenerator  with  a  release  con- 
firmed acknowledgment.  As  before,  the  module  transitions  to  the  dispatch 
state. 

•  check  channel.  When  the  calLgenerator  receives  the  signal  that  the  release 
was  confirmed,  the  calLgenerator  notifies  the  call_scheduler  that  the  channel  is 
available.  This  signal  forces  a  transition  to  the  check  channel  state  where 
the  channel  list  is  checked  for  additional  calls  waiting.  If  additional  calls  are 
scheduled  on  the  channel,  the  module  generates  an  event  to  start  the  next  call 
on  the  channel. 

•  call  release.  This  state  is  released  when  the  calLgenerator  sends  a  call  con- 
nection request  to  the  AAL  module  and  the  AAL  module  responds  with  a  call 
rejection.  The  module  invokes  the  required  calLgenerator  and  passes  along  the 
call  rejection  signal. 

•  reschedule.  When  the  calLgenerator  receives  a  call  rejection  signal,  it  creates 
a  call  reschedule  request  and  signals  the  calljscheduler  to  reschedule  the  call. 
The  signal  to  reschedule  forces  a  transition  to  the  reschedule  state  which 
places  the  call  request  at  the  head  of  the  calls_pending  list  for  rescheduling. 
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•  error.  The  code  in  this  state  processes  unexpected  signals. 

•  End  Sim.  The  code  in  this  state  prints  reports  at  the  end  of  the  simulation. 

3.        BADD  Call  Generator 

The  dynamic  call_generator  process  is  created  and  invoked  by  the  call-scheduler 
module  to  manage  individual  call  requests.  This  process  initiates  the  call  connection 
request,  generates  data  for  the  call,  and  releases  the  call  upon  its  completion.  Figure  51 
shows  our  new  call-generator  process.  A  description  of  these  states  is  given  below. 


(default) 


(default) 


(default)    I 


(REL_C0H) 


Figure  51.  State  diagram  for  BADD  calLgenerator  process. 


INIT.  The  calLgenerator  enters  this  state  only  upon  initial  invocation  by  the 
calljscheduler  module.  This  state  accepts  the  call  request  Ici  packet  and  initial- 
izes the  state  variables  that  describe  the  call  request.  Additionally,  this  state 
accesses  the  shared  memory  initialized  by  the  call_scheduler  and  retrieves  the 
index  identifying  the  packet  stream  to  the  AAL  module.  All  call  requests  and 
the  call  data  are  sent  to  the  AAL  module  using  this  stream  index. 


102 


•  start.  With  the  automatic  transition  to  this  state,  the  call_generator  creates  a 
badcLcalLgen JLici  packet  describing  the  connection  required  to  support  this 
call.  It  includes  this  packet  in  the  call  connection  request  sent  to  the  AAL 
module.  This  process  then  goes  to  sleep  in  this  state,  awaiting  a  wake-up 
signal  from  the  calljscheduler  module. 

•  EstCon.  The  call -generator  received  a  wake-up  signal  from  the  call  .scheduler 
and  the  signal  contains  the  response  for  the  connection  request  sent  to  the  AAL 
module.  If  the  signal  is  an  established  connection  signal,  this  state  generates 
a  delayed  self  interrupt  to  signal  the  call  termination  and  then  generates  an 
immediate  interrupt  to  signal  generation  of  the  first  data  packet.  Control  im- 
mediately transfers  to  the  data  gen  state.  If  the  signal  from  the  calljscheduler 
indicates  call  rejection  by  the  AAL  module,  this  state  transfers  control  to  the 
reschedule  state. 

•  data  gen.  This  state  continues  to  generate  data  packets  until  the  call  completes 
or  the  calljscheduler  sends  a  network  release  indication.  Upon  receiving  the 
interrupt  signaling  call  completion,  this  state  sends  a  call  release  request  to  the 
AAL  module  and  transitions  to  the  RelCon  state.  If  the  network  signals  with 
a  connection  release,  this  state  transitions  to  the  reschedule  state. 

•  RelCon.  After  completing  the  call  and  sending  the  release  request,  this  state 
sleeps  until  the  network  responds  with  a  release  confirmed  signal.  This  signal 
forces  the  transition  to  the  call  done  state. 

•  reschedule.  When  a  call  is  rejected  by  the  network,  or  the  network  signals 
a  call  release  during  data  transmission,  the  current  call  requires  rescheduling. 
This  state  creates  a  call  request  that  is  forwarded  to  the  calljscheduler  module. 
This  state  then  signals  the  calljscheduler  module  that  the  channel  is  available 
and  then  destroys  this  process. 

•  call  done.  When  the  call  is  completed  and  all  network  resource  are  released, 
this  state  signals  the  calljscheduler  module  that  the  channel  is  available  and 
then  destroys  this  process. 


E.       SUMMARY 

In  this  chapter  we  have  explained,  in  detail,  the  design  and  implementation  of 
our  OPNET  Model  of  the  BADD  network.  Due  to  the  complexity  of  the  simulation 
model,  we  have  only  been  able  to  elaborate  on  the  most  significant  aspects  of  our 
design.  Additional  information  can  be  found  in  Appendices  C  through  F  which 
contain  the  OPNET  reports  for  the  processes  designed  to  support  our  simulations. 
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Now  that  our  simulation  model  is  defined  it  is  time  to  put  it  to  work.  The  next  chapt 
describes  our  simulation  testing  plan,  our  results,  and  conclusions. 
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VII.         ANALYSIS  AND  RECOMMENDATIONS 

In  this  chapter  we  describe  our  experiments  and  the  results  of  our  testing.  Since 
most  of  our  efforts  concentrated  on  the  construction  of  the  simulation  of  BADD,  we 
provide  a  section  on  our  observations  from  using  OPNET  as  a  network  development 
tool  as  well  as  one  on  lessons  learned.  We  also  make  recommendations  for  new  features 
that  we  would  like  to  see  in  a  tool  for  building  prototype  networks.  Finally,  we  describe 
possible  areas  of  future  research  that  build  upon  our  simulation  model. 

A.      TESTING 

We  conducted  multiple  runs  of  our  simulator  using  both  the  default  FIFO 
scheduler  and  our  Greedy  scheduler  implementation.  We  initially  validated  our  basic 
model  using  only  a  single  data  generation  source  and  channel.  We  validated  our 
design  and  ensured  the  correctness  of  the  values  generated  by  the  simulation.  After 
verifying  the  correctness  of  our  basic  model,  we  ran  additional  simulations  varying 
the  parameters  described  in  Table  XII  using  small  data  sets  as  reflected  by  the  short 
durations  of  the  calls  and  the  small  numbers  of  channels  and  requesters.  Small  data 
sets  were  used  to  determine  the  sensitivity  of  our  simulations  to  changes  of  various 
parameters.  Next  we  conducted  additional  runs  to  determine  whether  our  analysis  of 
the  smaller  data  sets  holds  for  the  larger,  more  realistic  data  sets.  Finally,  we  used  an 
exponential  distribution  for  the  interarrival  rates  and  wait  times  of  the  call  requesters 
to  determine  whether  our  analysis  held  for  more  general  cases. 

1.        Simulation  Duration 

We  varied  the  runtime  of  our  simulation  between  10  and  50  seconds.  A  runtime 
of  at  least  1 0  seconds  was  needed  to  allow  the  simulation  to  complete  its  warmup  phase, 
a  phase  that  is  common  to  all  simulations  [Ref.  17].  We  selected  the  maximum  of  50 
seconds  because,  by  that  time,  the  bit  throughput  clearly  approached  its  asymptotic 
limit  as  reflected  in  Figure  52.    OPNET  simulations  complete  in  any  of  three  ways: 
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Parameter 

Range 

Duration  of  Simulation 

10  to  50  seconds 

Number  of  Requesters 

1  to  16 

Number  of  Channels 

2  to  20 

Data  Sources  and 
Channel  Characterization 

nearly  homogeneous  to  heterogeneous 

Table  XII.  Simulation  Parameters  and  Ranges  of  Values 

(i)  when  the  simulated  time  reaches  a  certain  value,  (ii)  when  a  module  within  the 
network  reaches  a  final  state,  or  (iii)  in  unusual  circumstances,  when  the  event  list 
is  empty.  We  used  the  first  option  and  set  a  simulation  completion  time  to  end  our 
simulation. 


CL3VR_MET  .  6upl«x_3     f  0  ]  .  bit_thn»p«t    (xjr»07) 


Figure  52.  Greedy  bit  throughput  results  after  100  Seconds. 

2.        Channels 

We  varied  the  number  of  channels  between  2  and  20  in  order  to  provide  a  wide 
range  for  analysis.  The  BADD  architecture  proposes  to  use  1024  channels  on  this  8 
Megabit  link.  This  configuration  requires  that  the  bandwidth  on  individual  channels  be 
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very  small.  Since  one  of  the  requirements  of  B  ADD  is  to  broadcast  bandwidth  intensive 
application  we  believe  that  some  large  channels  are  required.  The  use  of  a  few  large 
bandwidth  channels  brings  down  the  total  number  of  usable  channels  drastically.  In 
fact,  we  constructed  a  bandwidth  allocation  Lotus  1-2-3  spreadsheet  and  determined 
that  we  could  get  a  good  mix  of  channels,  of  standard  size,  if  we  limit  the  total 
number  of  channels  to  20.  Typically,  telecommunication  channels  are  allocated  in 
bits-per-second  (bps)  with  standard  capacities  being  64  kilobits-per-second  (Kbps), 
128  Kbps,  256  Kbps,  512  Kbps,  and  1.544  megabits-per-second  (Mbps).  We  confined 
ourselves  to  using  a  mix  of  these  standard  channel  capacities  as  shown  in  Table  XIII. 
We  used  the  smaller  values  in  the  table  to  perform  our  sensitivity  analysis  on  our 
other  test  parameters.  We  recognized  that  BADD's  8Mbps  channel  would  not  be 
completely  utilized  during  the  simulations  with  8  or  fewer  channels.  Nonetheless, 
these  experiments  permitted  us  to  perform  the  sensitivity  analysis  to  determine  which 
parameters  most  influenced  the  simulation  results. 

In  Table  XIII  we  list  2  columns,  heterogeneous  and  homogeneous  channel 
mixes.  We  provide  these  columns  to  support  our  definition  of  heterogeneous  and 
homogeneous  experiments.  For  heterogeneous  experiments  we  will  use  heterogeneous 
data  sources  over  heterogeneous  channels.  Similarly,  for  homogeneous  experiments  we 
will  use  homogeneous  data  sources  over  homogeneous  channels.  These  data  source 
classifications  will  be  discussed  fully  in  the  next  section. 

3.       Number  of  Call  Requesters  and  Data  Sources 

We  varied  the  number  of  requesters  between  2  and  16.  We  were  constrained  to 
16  by  OPNET's  limitations  on  the  numbers  of  requesters  that  can  be  connected  into 
the  AAL  module.  The  OPNET  GUI  for  building  nodes  does  not  allow  the  lines  that 
represent  data  streams  that  connect  modules  to  intersect.  Because  of  the  physical 
limits  of  connecting  data  streams  graphically,  we  experienced  difficulty  when  we  tried 
to  use  more  than  16  requesters. 

Table  XIV  lists  the  variety  of  data  sources  that  we  used  for  testing  with  smaller 
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Number  of  Channels 
Allocated 

Heterogeneous 
Mix  of  Channels 

Homogeneous 
Mix  of  Channels 

2 

1.544  Mbps  (xl) 
256  Kbps  (xl) 

512  Kbps  (x2) 

4 

1.544  Mbps  (xl) 
512  Kbps  (xl) 
256  Kbps  (xl) 

512  Kbps  (x2) 
256  Kbps  (x2) 

8 

1.544  Mbps  (x2) 
512  Kbps  (x2) 
256  Kbps  (x2) 
128  Kbps  (xl) 
64  Kbps  (xl) 

512  Kbps  (x4) 
256  Kbps  (x4) 

20 

1.544  Mbps  (x3) 
512  Kbps  (x2) 
256  Kbps  (x4) 
128  Kbps  (x4) 
64  Kbps  (x7) 

512  Kbps  (x6) 
256  Kbps  (x8) 
128  Kbps  (x6) 

Table  XIII.  BADD  Channel  Allocations  for  Various  Channel  Configurations. 

data  sets.  Table  XV  shows  the  various  mixes  of  application  types  that  we  used  in 
these  simulations.  In  our  smaller  tests,  as  well  as  with  our  larger  tests,  we  wanted 
a  mix  of  applications  that  would  be  representative  of  those  that  we  would  expect  to 
see  sent  over  the  BADD  network.  The  values  in  the  table  were  loosely  based  upon 
those  used  in  Joint  Task  Force  (JTF)  Advanced  Technology  Demonstration  (ATD) 
experiment  in  1995  [Ref.  19].  After  completing  simulations  on  the  smaller  data  sets, 
we  used  exactly  the  same  data  as  that  used  in  the  JTF  ATD  experiment  as  shown  in 
Table  XVI.  Table  XVII  shows  the  mix  of  requesters  we  used  for  our  heterogeneous 
and  homogeneous  runs.  Below  we  expand  upon  the  sizes  of  messages  generated  by 
the  various  JTF  ATD  applications. 

1.  Database  Views  (DB)  -  The  mean  of  message  sizes  is  1  Mbyte.  We  used  both 
this  value  and  smaller  value  of  500  Kbytes  with  a  constant  distribution. 

2.  Email  -  Ranged  from  100  bytes  for  text  only  systems  to  1  Mbyte  systems 
capable  of  handling  graphical  attachments.  We  selected  values  of  1  Mbyte,  250 
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Kbytes,  and  500  bytes  to  represent  these  ranges  using  a  constant  distribution. 

3.  Web  Masters  -  Ranged  from  500  bytes  to  50  Kbytes.  We  selected  values  of 
1  Kbyte  and  50  Kbytes  to  represent  this  range.  Again  we  used  a  constant 
distribution  to  generate  these  packets  in  our  simulation. 

4.  Video  -  This  value  did  not  come  from  the  JTF  ATD  experiment.  We  calculated 
this  value  based  upon  a  UAV  transmission  rate  of  64Kbps.  We  assumed  that 
a  commander  would  be  interested  in  the  UAV's  flight  over  his  area  of  interest 
and  that  the  time  required  for  fly  over  would  be  2  minutes.  Based  upon  this 
time  constraint,  and  the  data  rate  the  UAV  sends  data  to  the  ground  station, 
we  calculated  the  size  of  1  MByte  for  this  message  (message  size  =  64Kbps  * 
60  seconds  *  2  minutes  *  (Igf)). 


Data  Source 

Wait 

Call  Size 

BPS  Production  Rate 

Large  DB  View 

1.0 

338  Kbytes 

1.35M 

Video 

0.2 

135  Kbytes 

1.0M 

Large  Email 

0.1 

63  Kbytes 

507K 

Large  Web 

0.5 

32  Kbytes 

256K 

Small  DB  View 

0.001 

206  bytes 

165K 

Medium  Email 

0.01 

16  Kbytes 

126K 

Small  Web 

0.01 

9.9  Kbytes 

79K 

Small  Email 

0.0011 

675  bytes 

54K 

Table  XIV.  Representative  Simulation  Data  Sources 

We  now  discuss  our  choice  of  homogeneous  and  heterogeneous  mix  of  data 
sources  in  more  detail.  We  use  the  term  homogeneous  to  mean  that  calls  generated  by 
the  data  sources  have  similar  bit  production  rates.  A  heterogeneous  mix  means  that 
there  is  more  variety  in  these  production  rates.  An  example  of  a  heterogeneous  set  of 
sources  that  we  used  had  one  1.581  Mbps  source,  one  501.894  Kbps  source,  one  250.95 
Kbps  source,  and  one  65.34  Kbps  source.  A  homogeneous  set  of  4  sources  consisted 
of  two  501.894  Kbps  sources  and  two  250.95  Kbps  sources. 


109 


Number  of  Requesters 
Allocated 

Heterogeneous 
Mix  of  Requesters 

Homogeneous 
Mix  of  Requesters 

2 

Large  DB  Views  (xl) 
Small  Email  (xl) 

Large  Email  (x2) 

4 

Large  DB  View  (xl) 
Large  Email  (xl) 
Small  DB  Views  (xl) 
Small  Email  (xl) 

Large  Email  (x2) 
Large  Web  (x2) 

8 

Large  DB  View  (xl) 
Video  (xl) 
Large  Email  (xl) 
Large  Web  (xl) 
Small  DB  View  (xl) 
Medium  Email  (xl) 
Small  Web  (xl) 
Small  Email  (xl) 

Large  Email  (x4) 
Large  Web  (x4) 

Table  XV.  Requester  Configurations  for  Testing  Small  Data  Sets 

B.      RESULTS 

In  Figure  53  we  provide  the  results  of  our  testing  for  both  of  the  schedulers 
using  small  data  sets.  The  column  label  indicates  the  runtimes  of  our  simulations  in 
seconds.  The  row  labels  indicate  the  configuration  of  the  requesters  and  the  number  of 
servicing  channels.  The  rows  are  each  divided  into  sub-rows.  The  top  entry  for  each 


Data  Source 

Wait 

Call  Size 

BPS  Production  Rate 

Large  DB  Views 

0.0007 

1.0  Mbytes 

1.581M 

Large  Email 

0.0022 

1.0  Mbytes 

501.894K 

2  Min  Video 

0.0007 

1.0  Mbytes 

1.581M 

Small  DB  Views 

0.0022 

500  Kbytes 

501.894K 

Medium  Email 

0.0044 

250  Kbytes 

250.95K 

Large  Web  View 

0.009 

50  Kbytes 

122.69K 

Small  Web  View 

0.0169 

1  Kbytes 

65.34K 

Small  Email 

0.0169 

500  bytes 

65.34K 

Table  XVI.  Realistic  Simulation  Data  Sources  (Derived  From  [Ref.  19]). 
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Number  of  Requesters 

Heterogeneous 

Homogeneous 

Allocated 

Mix  of  Requesters 

Mix  of  Requesters 

16 

Large  DB  Views  (x2) 

Small  DB  Views  (x4) 

Large  Email  (x2) 

Medium  Email  (x8) 

2  Min  Video  (x2) 

Large  Web  View  (x4) 

Small  DB  Views  (x2) 

Medium  Email  (x2) 

Large  Web  View  (x2) 

Small  Web  View  (x2) 

Small  Email  (x2) 

Table  XVII.  Channel  Allocations  for  16  Requester  Configurations. 

sub-row  is  the  average  bit  throughput.  The  bottom  entry  is  the  completion  time  of 
the  last  scheduled  transmission  if  all  transmissions  are  allowed  to  run  to  completion. 
Note  that  we  also  simultaneously  vary  the  mix  of  the  data  requesters  and  channels  as 
depicted  by  the  partitioning  of  the  columns. 

We  provide  the  results  of  our  testing  for  the  realistically  sized  data  in  Figure  54 
in  the  same  format  as  Figure  53.  We  eliminated  the  10  and  25  second  runtimes  because 
they  do  not  provide  any  new  data.  (Instead,  we  looked  at  varying  the  input  from  the 
requesters  from  a  constant  distribution  to  an  exponential  distribution.)  In  the  next 
section  we  provide  the  analysis  of  these  results. 

C.      ANALYSIS  OF  RESULTS 

This  section  provides  the  analysis  of  testing  that  allowed  us  to  make  certain 
conclusions  about  the  nature  of  the  BADD  architecture  with  different  schedulers. 

1.        Effects  of  Satellite  Delay  on  ATM  Protocol 

OPNET  provides  direct  support  for  modeling  duplex  ATM  networks.  Earlier 
we  described  how  we  modified  these  models  to  approximate  BADD's  simplex  ATM 
protocol.  These  models  allow  the  user  to  insert  delays,  which  are  normally  small, 
between  ATM  switches.  However,  since  the  BADD  architecture  uses  a  Global  Broad- 
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Figure  53.  Representative  Test  Results 
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Figure  54.  Realistic  Test  Results 

cast  Satellite  (GBS)  satellite  in  geosynchronous  orbit,  we  must  use  a  fairly  large  delay 
of  0.250  seconds,  which  is  more  typical  of  geosynchronous  satellite  propagation  [Ref. 
6]. 

For  comparison,  we  did  execute  the  original  OPNET  dynamic  virtual  channel 
duplex  protocol  using  the  0.25  second  delay.  Our  first  observation  is  that  the  duplex 
ATM  protocol  is  not  efficient  when  using  links  with  large  delays  because  of  the  setup 
signaling  requirements  in  the  protocol.  Figure  55  shows  that  the  these  requirements 
require  the  channel  to  be  idle  for  large  periods  of  time  "while  awaiting  responses  to 
establish  and  terminate  call  setups.  This  idle  time  clearly  reduces  the  amount  of 
data  transmitted  over  the  network  and  lowers  the  bit  throughput  rate.  Therefore  we 
conclude  that  although  the  BADD  designers  chose  a  simplex  implementation  for  a 
different  reason,  a  duplex  implementation  for  a  BADD-like  architectures  should  never 
be  considered  due  to  the  low  bit  throughput  rate  caused  by  the  combination  of  large 
propagation  delays  with  dynamic  virtual  channels. 

We  see  two  areas  that  are  worthy  of  further  investigation.  One  is  the  incor- 
poration into  OPNET  of  a  simplex  ATM  protocol.  The  second  is  an  investigation  of 
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Figure  55.  Effects  of  Large  Delay  on  Link  Utilization 

the  use  of  Low  Earth  Orbit  (LEO)  satellites  rather  than  geosynchronous  satellites  in 
BADD.  The  use  of  LEO  satellites  would  require  modification  of  the  protocol  because 
the  LEO  satellite  is  moving;  however,  the  propagation  delays  would  be  significantly 
decreased  to  approximately  .005  seconds,  a  value  from  the  planned  Teledesic  Satellite 
System  orbiting  between  695  and  705  kilometers  [Ref.  20]. 

2.       Effects  of  Varying  Simulation  Parameters 

Our  experimental  results  shown  above  indicate  that  scheduler  performance  was 
independent  of 

1.  the  number  of  sources, 

2.  the  number  of  calls,  and 

3.  the  duration  of  our  simulation. 

However  it  depends  heavily  on  the  heterogeneity  of  both  the  sources  and  the 
channels.  We  found  that  the  FIFO  algorithm  occasionally  outperforms  the  Greedy 
algorithm  with  simulations  run  with  homogeneous  sources  and  channels,  that  is  when 
the  bandwidth  requirements  of  the  sources  were  nearly  identical  to  each  other  as  well 
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as  the  capability  of  the  channels.  However,  in  all  other  cases  the  Greedy  scheduler 
provides  a  better  schedule.  In  the  following  subsections,  we  provide  results  of  simula- 
tions with  the  16  requesters  and  the  20  channels  denned  in  the  previous  section. 

a.  Completion  Time  Observations 

Using  the  multiple  sources  shown  in  Table  XVII,  we  found  that  the 
total  channel  utilization  using  either  the  Greedy  or  FIFO  scheduler  is  approximately 
the  same.  Figure  56  compares  the  completion  times  of  channels  using  both  the  Greedy 
and  FIFO  schedulers.  While  the  average  channel  completion  time  using  either  of  these 
schedulers  is  approximately  72  seconds,  the  Greedy  scheduler  provides  a  much  more 
uniform  set  of  completion  times.  When  evaluating  the  worst  completion  times  of 
the  schedules,  we  find  that  Greedy's  worst  completion  time  is  92.79  seconds  whereas 
FIFO's  worst  time  is  174.42  seconds.  The  worst  FIFO  channel  takes  88  percent  longer 
than  the  worst  Greedy  channel. 
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Figure  56.   Greedy  vs.   FIFO  Channel  Completion  Times  for  Heterogeneous  Sources 
and  Channels 

To  help  explain  these  results,  Figure  57  shows  the  Estimated  Time  of 
Completion  (ETC)  Matrix  that  provides  the  key  reason  why  both  schedulers  have  the 
same  average  completion  time.  When  our  requester  generates  a  call,  the  first  step  is 
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Figure  57.  Estimated  Time  of  Completion  Matrix 

to  determine  which  channels  can  support  the  transmission.  In  our  ETC  matrix  we 
display  some  empty  entries.  These  empty  entries  are  result  of  the  channels  inability 
to  support  the  traffic  and  need  not  be  evaluated  by  the  scheduler.  We  also  notice  that 
each  call  requires  the  same  amount  of  time  on  each  virtual  channel.  The  reason  why 
all  VCs  have  the  same  value  for  a  given  call  is  because  we  considered  only  one  signaling 
characteristic,  transmission  rate.  When  other  characteristics  such  as  bit  error  rate  are 
taken  into  consideration  we  would  not  see  the  same  values  in  all  supporting  VCs  for 
a  particular  call.  Our  implementation,  with  the  same  estimated  completion  values  for 
each  call,  independent  of  VC,  causes  both  schedulers  to  have  the  same  finishing  times 
because  the  number  of  calls  requested  are  the  same  and  the  servicing  times  for  the  calls 
are  the  same.  In  other  words,  even  though  the  schedulers  place  the  calls  on  different 
channels,  the  aggregate  time  to  run  the  calls  will  be  the  same  for  both  schedulers. 

b.  Bit  Throughput  Observations 

Using  a  heterogeneous  set  of  sources  we  found  that  the  use  of  the  Greedy 
algorithm  yields  better  bit  throughput  than  the  use  of  the  FIFO  algorithm.  Figures  58 
and  59  show  that  the  bit  throughput  for  Greedy  averages  approximately  5.4  Mbps 
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while  FIFO's  bit  throughput  averages  approximately  3.7  Mbps.  These  results  show 
a  46  percent  greater  average  bit  throughput  for  a  representative  set  of  sources  and 
channels. 

c.  Calls  Scheduled  vs  Calls  Completed 

Figures  60  and  61  show  a  distribution  diagram  of  the  number  of  calls 
scheduled  (dashed  lines)  vs.  the  number  of  calls  completed  on  each  of  the  channels 
(solid  lines).  We  see  that  the  number  of  calls  scheduled  for  each  channel  is  much 
more  uniform  for  the  FIFO  Algorithm.  This  demonstrates  an  innate  failure  of  the 
FIFO  algorithm  in  that  it  assigns  calls  to  channels  based  only  upon  the  number  of 
calls  scheduled.  FIFO  does  not  consider  the  length  of  the  calls,  but  only  that  the 
number  of  calls  are  evenly  split  between  channels.  We  also  observe  that  the  average 
difference  in  the  number  of  calls  scheduled  versus  the  number  of  calls  completed  is 
approximately  the  same  for  both  algorithms,  approximately  42  for  our  representative 
run.  The  difference  between  the  algorithms  is  that  the  variance  of  this  difference 
is  much  higher  for  the  Greedy  algorithm.  This  observation  makes  sense  because  the 
Greedy  algorithm  does  not  attempt  to  balance  the  number  of  calls,  but  rather  attempts 
to  minimize  the  completion  times. 

3.        OPNET  Observations  and  Recommendations 

OPNET  is  an  extremely  powerful  network  simulation  tool.  We  found  their 
libraries  useful  in  modifying  our  network  and  are  grateful  that  all  of  their  source  code 
is  provided.  We  found  that  once  our  basic  model  was  developed,  that  it  was  very 
easy  to  modify  with  the  GUI.  We  also  appreciated  that  a  discrete  event  simulator, 
supporting  different  distributions,  was  already  present  as  well  as  an  analysis  tool 
that  graphed  output  with  little  effort  from  the  user.  Clearly  OPNET  is  a  quality 
networking  tool.  However,  there  are  challenges  in  using  state-of-the-art  products  to 
model  next  generation  networks.  In  this  section  we  will  highlight  some  of  the  lessons 
we  learned  and  provide  recommendations  for  OPNET  and  other  modeling  tools. 

The  approach  taken  in  BADD  is  to  keep  things  simple  at  first  and  then  incre- 
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Figure  58.  Greedy  Bit  Throughput  for  Heterogeneous  Sources  and  Channels 
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Figure  59.  FIFO  Bit  Throughput  for  Heterogeneous  Sources  and  Channels 
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Figure  60.  Greedy  Algorithm:  Calls  Scheduled  vs.  Calls  Completed  for  Heterogeneous 
Sources  and  Channels 
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Figure  61.  FIFO  Algorithm:  Calls  Scheduled  vs.  Calls  Completed  for  Heterogeneous 
Sources  and  Channels 
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mentally  improve  the  features  of  the  architecture  as  the  users  become  more  comfortable 
with  the  equipment  and  as  industry  establishes  more  robust  capabilities  in  the  com- 
mercial market.  Therefore,  the  BADD  network  simplifies  the  ATM  architecture  by 
stripping  out  much  of  the  functionality  of  ATM.  OPNET's  models  are  based  on  using 
most  of  the  functionalities  defined  in  the  standard  duplex  ATM  protocol.  Because  of 
BADD's  design  decision  to  use  static  virtual  channels  on  simplex  links  we  were  forced 
to  greatly  modify  the  OPNET  code  and  support  utilities. 

At  first  we  found  it  difficult  to  design  our  network  using  their  standard  models 
because  they  differed  substantially  from  BADD.  The  tutorials  had  given  us  a  false 
sense  of  security  and  we  began  our  design  with  the  intent  of  making  modest  changes 
to  the  duplex  implementation.  As  we  became  more  familiar  with  the  tool,  we  recog- 
nized that  we  would  have  to  rewrite  the  OPNET  code  for  setup  and  tear  down  of 
dynamic  virtual  paths  and  virtual  channels.  Below  we  enumerate  some  of  the  lessons 
learned  from  our  simulation  design,  provide  our  observations  for  future  users,  and 
offer  suggestions  for  additional  features  we  would  like  to  see  OPNET  provide  in  the 
future. 

OPNET  requires  the  commitment  of  a  large  amount  of  time  before  the  user 
will  feel  comfortable  using  the  tools  for  advanced  research.  With  no  training,  a  vast 
amount  of  our  design  time  was  spent  developing  a  basic  working  network  model.  In 
order  to  gain  maximum  benefit  from  this  simulation  tool,  the  user  should  have  a 
thorough  understanding  of  the  network  and  the  associated  protocols  used  within  it. 
We  recommend  the  user  read  the  following  portions  of  the  OPNET  manuals  in  the 
order  we  specify. 

1.  Complete  the  Introduction  to  OPNET  Tutorial,  Basic  Model  Tutorial  and  one 
other  tutorial  to  get  a  feel  for  OPNET. 

2.  Read  the  first  Modeling  Manual  in  detail  on  the  Modeling  Overview,  Modeling 
Framework,  and  Process  Domain  Definitions. 

3.  Read  the  particular  section  on  the  model  or  protocol  that  the  user  is  interested 
in  modeling. 
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If  we  had  carefully  read  these  sections  in  the  above  order,  we  would  have  saved  a 
month  of  our  time  learning  the  tool.  We  continually  found  ourselves  going  back  to 
these  sections  to  refresh  our  understanding  of  how  OPNET  worked. 

Below  we  make  some  suggestions  for  enhancing  OPNET  to  make  it  more  useful 
for  tomorrow's  network  designers.  We  separate  our  suggestions  into  major  and  minor 
categories. 

a.  Major  Enhancements  Recommended  for  OPNET 

1.  MIL  3  should  consider  providing  packet  generators  and  queue  models  at  the 
process  and  node  level.  Currently,  OPNET  implements  numerous  functions, 
such  as  packet  generators  and  queues,  only  at  the  node  level.  During  our 
design,  we  required  these  functions  at  the  process  level  which  forced  us  to 
write  these  functions  as  processes  within  our  model. 

2.  We  believe  that  simplex  ATM,  particularly  when  used  in  conjunction  with 
geosynchronous  satellite  broadcast,  will  be  an  important  protocol  of  the  future. 
We  therefore  believe  that  MIL  3  should  consider  providing  a  simplex  ATM 
protocol. 

3.  Running  OPNET  simulations  from  the  command  line  is  neither  intuitive  nor 
user  friendly.  During  our  model  development,  our  system's  administrator  up- 
graded the  operating  system  and  we  lost  access  to  the  OPNET  Graphical  User 
Interface  for  three  weeks.  The  External  Interfaces  Manual  describes  only  basic 
command  line  syntax  and  the  command  line  options  are  spread  over  several 
different  chapters  in  the  manual.  Giving  the  command  line  syntax  with  all 
available  options  in  one  section  would  drastically  improve  the  usefulness  of  the 
manual. 

4.  MIL  3  should  consider  providing  a  GUI  utility  to  allow  the  user  to  save  simula- 
tion runs,  enabled  with  traces,  to  a  file  for  further  analysis.  We  needed  to  run 
self-produced  scripts  from  the  command  line  in  order  to  save  data  into  scripts 
for  analysis.  Some  operations  required  invocation  of  debug  operations  in  order 
to  capture  the  status  of  data  throughout  the  simulation. 

b.  Minor  Enhancements  Recommended  for  OPNET 

1 .  We  recommend  that  MIL  3  look  at  reimplementing  their  code  to  calculate  the 
Peak  Cell  Rate  (PCR)  in  the  ams_traf_gen  process  as  floating  point  division. 
The  current  implementation  does  integer  division.  Subsequently  a  conditional 
checks  the  value  of  the  PCR  and  assigns  the  value  of  1  to  all  calculations  less 
than  one. 
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2.  We  were  constrained  by  OPNET's  limitations  on  the  numbers  of  requesters 
that  can  be  fed  into  the  AAL  module.  OPNET  should  provide  a  method,  at 
the  module  level,  that  allows  the  modeler  to  include  large  numbers  of  data 
generators  into  the  AAL  module. 

4.        Parallelization  of  Scheduling  Algorithms 

We  examined  the  possibility  of  using  parallel  processors  to  improve  the  speedup 
of  our  scheduling  algorithms.  These  efforts  were  done  independent  of  our  OPNET 
simulation. 

We  used  a  Silicon  Graphics  Challenge,  with  four  processors  to  parallelize  our 
Greedy  code.  Table  XVIII  shows  the  time  in  seconds  to  complete  scheduling  based 
on  the  number  of  calls.  The  speedup  calculations  are  based  upon  the  runtime  of  the 
C  code  on  one  processor  against  the  runtime  of  the  C  code  on  all  4  processors. 


Calls 

Channels 

Seq(C) 

Para(C) 

Speedup 

20 

16 

0.104 

0.542 

0.19 

100 

16 

0.12 

0.604 

0.20 

1000 

16 

2.967 

4.318 

0.69 

10000 

16 

287.053 

364.829 

0.79 

20000 

16 

1447.164 

1567.002 

0.92 

30000 

16 

2587.132 

2314.182 

1.12 

40000 

16 

4584.385 

3738.235 

1.23 

Table  XVIII.  SGI  Speedup  Calculations 
[SGI  Speedup  Calculations,  all  times  are  given  in  microseconds. 


D.      RECOMMENDATIONS  FOR  FUTURE  RESEARCH 
1.        Optimal  Scheduling  Times 

OPNET  discrete  event  simulations  service  events  under  the  assumption  that 
they  take  no  time  to  execute.  This  is  necessary  to  support  the  overhead  of  running 
a  simulation.  A  side  effect  of  this  design  is  that  calls  to  our  scheduling  algorithms 
do  not  require  any  simulation  time.    This  is  clearly  not  realistic.    We  investigated 
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incorporating  the  run  times  into  our  schedulers,  independent  of  the  simulation,  to  gain 
some  understanding  of  how  much  time  it  takes  to  run  the  scheduling  algorithms.  We 
found  that  the  runtime  of  the  algorithm  was  proportional  to  size  of  squaring  our  input 
to  the  algorithm.  We  used  this  rough  estimate  to  calculate  a  delay  for  scheduling 
but  did  not  include  this  modification  in  the  simulation  due  to  time  constraints.  The 
inclusion  of  this  modification  is  absolutely  necessary  to  perform  a  cost-benefit  analysis 
of  integrating  the  scheduling.  It  is  also  necessary  in  determining  the  optimal  time  to 
wait  before  calling  the  scheduler. 

2.  Implementation  with  Static  Virtual  Paths  vs.   Static 
Virtual  Channels 

We  recommend  that  simulation  of  the  BADD  network  be  modeled  with  static 
virtual  paths  rather  than  static  virtual  channels.  This  model  would  be  more  natural 
to  the  OPNET  ATM  protocols  and  would  preserve  the  flexibility  of  dynamic  virtual 
channel  allocation  within  the  static  virtual  paths.  The  preservation  of  dynamic  alloc- 
ation would  provide  flexibility  for  schedules  to  use  the  large  bandwidth  paths  to  send 
multiple  small  calls  when  they  are  not  sending  large  calls  over  the  path. 

3.  Inclusion  of  Attributes  in  Scheduling  Algorithm 

Our  current  scheduler  makes  its  decisions  based  upon  completion  time  only. 
A  better  implementation  would  include  considerations  for  other  attributes  such  as 
bit  error  rate  and  jitter  characteristics  of  the  various  channels.  A  more  comprehens- 
ive scheduler  could  accomplish  this  by  applying  weighting  factors  for  each  desired 
attribute. 

E.       SUMMARY 

The  use  of  OPNET  to  model  communication  networks  is  highly  advantageous 
because  it  provides  an  extensive  array  of  tools  to  support  simulation  development 
and  analysis.  When  developing  new  protocols  there  is  significant  time  required  to 
understand  the  complexities  of  OPNET  before  the  user  can  achieve  their  desired 
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modeling  results. 

The  use  of  the  0(n2m)  Greedy  algorithm  will  decrease  the  time  required  to 
completely  process  all  calls.  Our  results  indicate  that  the  BADD  program  should 
consider  integrating  this  algorithm  into  their  current  architecture  in  order  to  increase 
the  performance  of  the  network. 
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APPENDIX  A.  ABBREVIATIONS  AND 

DEFINITIONS 

The  following  listing  of  abbreviations  and  definitions  includes  an  abridged 
and  extended  version  of  Cisco  Internetworking  Terms  and  Acronyms.  The  abridge- 
ment is  based  on  terms  used  in  this  thesis.  The  original  glossary  can  be  found  at 
http://www.erl.noaa.gov/noc/cisco/data/doc/cintrnet/ita.htm 


•  ACK  Flag.  A  bit  that,  when  set,  alerts  the  protocol  that  the  acknowledgment 
number  is  valid. 

•  ACTD  Advanced  Concepts  Technology  Demonstration. 

•  AHPCA  Advanced  High  Performance  Computing  Applications. 

•  Address  Translation.  The  process  of  converting  external  addresses  into 
standardized  network  addresses  and  vice  versa.  It  facilitates  the  interconnec- 
tion of  multiple  networks  in  which  each  have  their  own  addressing  scheme. 

•  Analog  A  type  of  transmission  in  which  a  continuously  variable  signal  encodes 
an  infinite  number  of  values  for  the  information  being  sent.  (Compare  with 
"digital") 

•  ANSI  The  American  National  Standards  Institute  is  a  US-based  organization 
that  develops  standards  and  defines  interfaces  for  telecommunications  systems. 

•  ABCS  Army  Battle  Command  System. 

•  Asynchronous  A  term  used  to  describe  any  transmission  technique  that  does 
not  require  a  common  clock  between  the  two  communicating  devices,  but  in- 
stead derives  timing  signals  from  special  bits  or  characters  (i.e.,  start/stop  bits, 
flag  characters)  in  the  data  stream  itself.  (Compare  with  "synchronous.") 

•  Asynchronous  Transfer  Mode  (ATM)  A  form  of  digital  transmission  based 
on  the  transfer  of  units  of  information  known  as  cells.  It  is  suitable  for  the 
transmission  of  image,  voice,  video,  and  data. 

•  ATM  Asynchronous  Transfer  Mode. 
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•  ATM  Adaptation  Layer  (AAL)  The  AAL  translates  digital  voice,  image, 
video,  and  data  signals  into  the  ATM  cell  format  and  vice  versa.  Five  AALs 
are  defined: 

—  AALl  supports  connection-oriented  services  needing  constant  bit  rates 
and  specific  timing  and  delay  requirements,  (e.g.,  DS-3  circuit) 

—  AAL2  supports  connection-oriented  services  needing  variable  bit  rates, 
(e.g.,  certain  video  transmission  schemes) 

—  AAL3/4  supports  both  connectionless  and  connection-oriented  variable 
rate  services. 

—  AAL5  supports  connection-oriented  variable  bit  rate  data  services.  AKA: 
Simple  and  Efficient  Adaptation  Layer  (SEAL) 

•  ATM  Application  Program  Interface  (API)  While  no  standard  ATM  API 
exists,  the  ATM  Forum  is  developing  an  API  that  enables  application  developers 
to  use  ATM's  quality  of  service  and  traffic  management  features.  In  the  mean- 
time, FORE  Systems  is  one  the  vendors  that  supply  an  API  library  with  its 
line  of  ATM  network  adapter  cards.  Services  such  as  guaranteed  bandwidth 
reservation,  per  connection  selection  of  AAL5  or  AAL3/4,  and  multicasting 
with  dynamic  addition  and  deletion  of  recipients  are  made  available  to  the  ap- 
plication. Applications  that  use  FORE's  ATM  API  bypass  inefficiencies  and 
overhead  associated  with  typical  TCP/IP  protocol  stacks. 

•  ATM  Layer  The  protocol  layer  that  relays  cells  from  one  ATM  node  to  an- 
other. It  handles  most  of  the  processing  and  routing  activities  including:  each 
cell's  ATM  header,  cell  muxing/demuxing,  header  validation,  payload-type 
identification,  quality-of-service  specification,  prioritization,  and  flow  control. 

•  Available  Bit  Rate  (ABR)  A  type  of  traffic  for  which  the  ATM  network 
attempts  to  meet  that  traffic's  bandwidth  requirements.  It  does  not  guaran- 
tee a  specific  amount  of  bandwidth  and  the  end  station  must  retransmit  any 
information  that  did  not  reach  the  far  end. 

•  BADD  Battlefield  Awarness  and  Data  Dissemination. 

•  BC2A  Bosnia  Command  and  Control  Augmentation  Initiative. 

•  Bandwidth  A  measure  of  capacity,  usually,  the  capacity  of  a  communica- 
tions line  to  transmit  voice,  data,  video,  or  image  traffic  through  a  network. 
Bandwidth  is  usually  expressed  in  bits  per  second  (bps),  thousands  of  bits  per 
second  (kbps),  millions  of  bits  per  second  (Mbps),  or  billions  of  bits  per  second 
(Gbps). 
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•  Border  Gateway  Protocol  (BGP)  A  protocol  used  by  gateway  devices  (e.g., 
routers)  in  an  internetwork,  connecting  autonomous  networks.  Based  on  the 
exterior  gateway  protocol. 

•  Broadband  A  service  or  system  requiring  transmission  channels  capable  of 
supporting  rates  greater  than  the  Integrated  Services  Digital  Network  (ISDN) 
primary  rate  (1.544  Mbps). 

•  Broadcast  (Messages)  Transmissions  sent  to  all  stations  (or  nodes,  or  devices) 
attached  to  the  network. 

•  BMC  Broadcast  Management  Center. 

•  Broadcast  and  Unknown  Server  (BUS)  In  LAN  Emulation,  a  LAN  Emu- 
lation server  provides  address  resolution  between  LAN  addresses  and  ATM 
network  addresses.  Multicast  traffic  and  unknown  traffic  (i.e.,  any  data  for 
which  the  sender  has  not  obtained  an  ATM  address)  require  different  proced- 
ures and  are  handled  by  the  broadcast  and  unknown  server. 

•  Buffer  An  area  of  storage  that  provides  an  uninterrupted  flow  of  data  between 
two  computing  devices. 

•  CCITT  The  Consultative  Committee  on  International  Telephony  and  Tele- 
graphy, now  the  International  Telecommunications  Union  (ITU),  is  an  interna- 
tional organization  that  develops  standards  and  defines  interfaces  for  telecom- 
munications systems. 

•  CNN  Cable  News  Network. 

•  Cell  A  transmission  unit  of  fixed  length  used  in  cell  relay  transmission  tech- 
niques such  as  ATM.  An  ATM  cell  is  made  up  of  53  bytes  (octets)  including  a 
5-byte  header  and  a  48-byte  data  payload. 

•  Cell  Delay  Variation  (CVD)  A  measurement  of  the  allowable  variation  in 
delay  between  the  reception  of  one  cell  and  the  next.  (Usually  expressed  in 
thousandths  of  a  second,  or  milliseconds  (msec).  Important  in  the  transmission 
of  voice  and  video  traffic,  CDV  measurements  determine  whether  or  not  cells 
are  arriving  at  the  far  end  too  late  to  reconstruct  a  valid  packet. 

•  Cell  Relay  Any  transmission  technique  that  uses  packets  of  a  fixed  length. 
ATM,  for  example,  is  a  version  of  cell  relay  using  53-byte  cells.  Other  versions 
use  cells  of  a  different  length. 

•  Cell  Loss  Priority  (CLP)  A  bit  in  the  ATM  cell  header  that  indicates  the 
cell's  transmission  priority.  If  the  bit  is  set  (value=l),  the  cell  is  eligible  to  be 
discarded,  if  it  is  not  (value=0),  it  cannot  be  discarded. 


127 


•  Circuit  Switching  A  switching  technique  in  which  a  dedicated  path  is  set  up 
between  the  transmitting  device  and  the  receiving  device,  remaining  in  place 
for  the  duration  of  the  connection,  (e.g.,  a  plain  old  telephone  call  is  a  circuit- 
switched  connection) 

•  Common  Part  Convergence  Sublayer  (CPCS)  The  part  of  an  ATM  ad- 
aptation layer's  convergence  sublayer  that  does  not  vary  with  the  type  of  traffic 
being  sent. 

•  Connection  Admission  Control  (CAC)  Methods  used  to  control  the  set  up 
of  switched  virtual  circuits.  For  example,  one  method  is  known  as  overbooking 
and  assumes  that  active  connections  are  not  using  all  of  the  available  band- 
width. Another  method,  known  as  full  booking,  limits  network  access  once 
all  bandwidth  is  committed.  Only  connections  that  request  acceptable  traffic 
parameters  are  permitted. 

•  Connection-oriented  A  type  of  communication  in  which  an  assigned  path 
must  exist  between  a  sender  and  a  receiver  before  a  transmission  occurs,  (e.g., 
circuit  switching)  ATM  networks  are  connection-oriented. 

•  Connectionless  A  type  of  communication  in  which  no  fixed  path  exists  between 
a  sender  and  receiver,  even  during  a  transmission,    (e.g.,  packet  switching) 
Shared  media  LANs  are  connectionless. 

•  COTS  commercial  off-the-shelf. 

•  Constant  Bit  Rate  (CBR)  A  type  of  traffic  that  requires  a  continuous,  spe- 
cific amount  of  bandwidth  over  the  ATM  network  (e.g.,  digital  information  such 
as  video  and  digitized  voice). 

•  C4I  Command,  Control,  Computer,  and  Intelligence. 

•  Digital  A  type  of  transmission  that  encodes  a  discrete  value  (e.g.,  "0"  or  "1") 
for  each  unit  of  information  being  encoded.  (Compare  with  "analog.") 

•  DARPA  Defense  Advanced  Research  and  Project  Agency. 

•  DIA  Defense  Intelligence  Agency. 

•  DIM  Downlink  Information  Manager. 

•  DISN  LES  Defense  Information  Systems  Network  Leading  Edge  Services. 

•  DMA  Defense  Mapping  Agency. 

•  DoD  Department  of  Defense. 
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•  Dual  Leaky  Buckets  A  method  employed  by  ATM  switches  to  perform  flow 
control  (traffic  policing)  on  ATM  network  connections.  Hardware  in  the  switch 
monitors  each  connection  to  determine  whether  it  has  exceeded  its  negotiated 
rate.  Dual  leaky  buckets  refers  to  the  use  of  one  "bucket"  to  monitor  the 
average  or  sustained  rate  and  one  to  monitor  the  peak  rate. 

•  EPLRS  VHSIC  Enhanced  Position  Location  Reporting  System  Very  High 
Speed  Integrated  Circuit. 

•  FIFO  First  In  First  Out. 

•  FIN  Flag.  This  bit  is  set  when  either  the  sender  or  receiver  finishes  with  a 
connection. 

•  Frame  Variable  length  packet  of  data  used  by  traditional  LANs  such  as  Eth- 
ernet and  Token  Ring  as  well  as  WAN  services  such  as  X.25  or  Frame  Relay. 
An  edge  switch  will  take  frames  and  divide  them  into  fixed-length  cells  using 
an  AAL  format.  A  destination  edge  switch  will  take  the  cells  and  reconstitute 
them  into  frames  for  final  delivery. 

•  GBS  Global  Broadcast  System. 

•  Generic  Flow  Control  (GFC)  The  first  four  bits  of  the  ATM  UNI  cell  header; 
used  when  passing  cells  to/from  the  UNI.  Setting  any  of  the  bits  in  this  field 
indicates  to  the  end  station  that  the  ATM  switch  can  implement  some  form  of 
congestion  control. 

•  Gigabits  Per  Second  (Gbps)  A  digital  transmission  speed  of  billions  of  bits 
per  second. 

•  GUI  Graphical  User  Interface. 

•  Header  Error  Control  (HEC)  An  8-bit  Cyclic  Redundancy  Code  (CRC) 
computed  on  all  fields  in  an  ATM  header;  capable  of  detecting  single  bit  and 
certain  multiple  bit  errors.  HEC  is  used  by  the  Physical  Layer  for  cell  delin- 
eation. 

•  HMMWV  High  Mobility  Military  Wheeled  Vehicle, 

•  ICI  Interface  Control  Information.  Used  by  OPNET  processes. 

•  IDS  Information  Dissemination  Server. 

•  IMETS  Integrated  Meteorological  System. 

•  IRD  Integrated  Receiver  Decoders. 
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•  ISO  International  Standards  Organization. 

•  1ST  Integrated  Systems  Technology. 

•  ITU-T  International  Telecommunication  Union  Telecommunication  Standard- 
ization Sector. 

•  Internet  Protocol  (IP)  Address  An  identifier  for  a  network  node;  expressed 
as  four  fields  separated  by  decimal  points  (e.g.,  136.19.0.5.);  IP  address  is  site- 
dependent  and  assigned  by  a  network  administrator. 

•  IP-over- ATM  The  adaptation  of  TCP/IP  and  its  address  resolution  protocol 
for  transmission  over  an  ATM  network.  It  is  defined  by  the  IETF  in  RFCs 
1483  and  1577.  It  puts  IP  packets  and  ARP  requests  directly  into  protocol 
data  units  and  converts  them  to  ATM  cells.  This  is  necessary  because  IP  does 
not  recognize  conventional  MAC-layer  protocols,  such  as  those  generated  on 
an  Ethernet  LAN. 

•  Local  Area  Network  (LAN)  A  system  consisting  of  computer  and  communic- 
ations hardware  and  software  connected  by  a  common  transmission  medium, 
usually  limited  to  a  scope  of  a  few  miles. 

•  LAN  Local  Area  Network. 

•  LDR  Low  Data  Rate. 

•  LNB  Low-Noise  Block. 

•  Link  Any  physical  connection  on  a  network  between  two  separate  devices,  such 
as  an  ATM  switch  and  its  associated  end  point  or  end  station. 

•  Megabits  Per  Second  (Mbps)  A  digital  transmission  speed  of  millions  of 
bits  per  second. 

•  MSE  Mobile  Subscriber  Equipment. 

•  Network-to-Network  Interface  (NNI)  In  an  ATM  network,  the  interface 
between  one  ATM  switch  and  another,  or  an  ATM  switch  and  a  public  ATM 
switching  system. 

•  NRaD  Naval  Command,  Control  and  Ocean  Surveillance  Center,  Research, 
Development,  Training,  and  Evaluation  Division 

•  OPNET  Optimized  Network  Engineering  Tools. 

•  OSI  Open  Systems  Interconnection. 
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Packet  Switching  A  switching  technique  in  which  no  dedicated  path  ex- 
ists between  the  transmitting  device  and  the  receiving  device.  Information  is 
formatted  into  individual  packets,  each  with  its  own  address.  The  packets  are 
sent  across  the  network  and  reassembled  at  the  receiving  station. 

PCM  Pulse  Code  Modulation. 

PIR  Priority  Information  Requirements. 

PSH  Flag.  This  bit,  when  set,  activates  the  Push  Function.  The  Push  func- 
tion pushes  this  packet  up  to  the  application  layer  even  if  the  buffer  is  not  yet 
full. 

Payload  Type  Identifier  (PTI)  The  3-bit  descriptor  in  an  ATM  cell  header 
that  indicates  whether  the  cell  is  a  user  cell  or  a  management  cell. 

Protocol  Data  Unit  (PDU)  A  unit  of  information  (e.g.,  packet  or  frame) 
exchanged  between  peer  layers  in  a  network. 

•  Permanent  Virtual  Circuit  (PVC)  A  generic  term  for  any  permanent,  pro- 
visioned communications  medium.  NOTE:  PVC  does  not  stand  for  permanent 
virtual  channel.  No  such  term  has  been  defined  by  any  standards  organization. 
Neither  has  the  term  "permanent  virtual  path  (PVP)."  In  ATM,  there  are  two 
kinds  of  PVCs:  permanent  virtual  path  connections  (PVPCs)  and  permanent 
virtual  channel  connections  (PVCCs). 

•  Physical  Layer  The  first  layer  in  the  OSI  Model.  It  specifies  the  physical 
interface  (e.g.,  connectors,  voltage  levels,  cable  types)  between  a  user  device 
and  the  network. 

•  Point-to-point  A  term  used  by  network  designers  to  describe  network  links 
that  have  only  one  possible  destination  for  a  transmission. 

•  Quality  of  Service  (QoS)  The  ATM  Forum  has  outlined  five  categories  of 
performance  (Classes  1  through  5)  and  recommends  that  ATM's  quality  of 
service  should  be  comparable  to  that  of  standard  digital  connections. 

•  RF  Radio  Frequency. 


• 
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RST  Flag.  This  bit  is  set  when  either  side  detects  problems  with  the  connec- 
tion and  the  connection  must  be  reset. 

Segmentation  and  Reassembly  (SAR)  The  process  of  converting  protocol 
data  units  into  ATM  cells  (i.e.,  adjusting  the  length  and  format).  At  the  far 
end,  the  SAR  process  takes  the  payload  out  of  the  ATM  cells  and  converts  it 
back  into  protocol  data  units. 
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•  SDR  Surrogate  Data  Radio. 

•  Signaling  (ATM)  The  procedures  used  to  establish  connections  on  a  ATM 
network.  Signaling  standards  are  based  on  the  ITU's  Q.93B  recommendation. 

•  SINCGARS  SIP  Single  Channel  Ground  and  Airborne  Radio  System  System 
Improvement  Program. 

•  SIV  System  Integration  Van. 

•  SPR  Secure  Packet  Radio. 

•  Switch  Device  used  to  route  cells  through  an  ATM  network. 

•  SSCS  Service  Specific  Convergence  Sublayer. 

•  Switched  Virtual  Circuit  (SVC)  A  generic  term  for  any  switched  commu- 
nications medium.  NOTE:  SVC  does  not  stand  for  switched  virtual  channel. 
No  such  term  has  been  defined  by  any  standards  organization.  Neither  has  the 
term  "switched  virtual  path  (SVP)."  In  ATM,  there  are  two  kinds  of  SVCs: 
switched  virtual  path  connections  (SVPCs)  and  switched  virtual  channel  con- 
nections (SVCCs). 

•  Sustainable  Cell  Rate  (SCR)  A  measure  of  the  maximum  throughput  that 
can  be  achieved  by  bursty  traffic  over  a  given  virtual  connection  without  the 
risk  of  cell  loss. 

•  Synchronous  A  term  used  to  describe  a  transmission  technique  that  requires  a 
common  clock  signal  (or  timing  reference)  between  two  communicating  devices 
to  coordinate  their  transmissions.  (Compare  with  "asynchronous.") 

•  Synchronous  Optical  NETwork  (SONET)  A  set  of  standards  for  the  digital 
transmission  of  information  over  fiber  optics.  Based  on  increments  of  51  Mbps. 

•  Synchronous  Transfer  Mode  (STM)  In  ATM,  a  method  of  communications 
that  transmits  data  streams  synchronized  to  a  common  clock  signal  (reference 
clock).  In  SDH,  it  is  "Synchronous  Transport  Module"  and  is  the  basic  unit 
(STM-1  =  155  Mbps,  STM-4=622  Mbps,  STM-16=2.5Gbps)  of  the  Synchron- 
ous Digital  Hierarchy. 

•  SYN  Flag.  A  bit  marking  this  packet  as  a  request  to  establish  a  connection. 

•  TCP  Transmission  Control  Protocol. 

•  TCP  HL.  TCP  HL  stands  for  TCP  Header  Length  and  specifies  the  total 
number  of  bytes  contained  in  the  header. 
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•  TEED  Tactical  End-to-End  Encryption  Device. 

•  TI  Tactical  Internet. 

•  TOC  Tactical  Operations  Center. 

•  TPN  Tactical  Packet  Network. 

•  Traffic  Shaping  A  mechanism  used  to  control  traffic  flow  so  that  a  specified 
Quality  of  Service  is  maintained. 

•  Usage  Parameter  Control  (UPC)  The  function  of  ATM  network  equipment 
that  controls  the  Cell  Loss  Priority  bit  to  control  congestion  on  the  network. 

•  UIM  Uplink  Information  Manager. 

•  UNI  User-Network  Interface. 

•  URG  Flag.  A  bit  that,  when  set,  tells  the  protocol  to  use  the  value  in  the 
Urgent  Pointer. 

•  UDP  User  Datagram  Protocol. 

•  User-to-Network  Interface  (UNI)  ATM  Forum  standard  that  defines  how 
private  CPE  interacts  with  private  ATM  switches.  A  connection  that  directly 
links  a  user's  device  to  an  ATM  network  (usually,  through  an  ATM  switch). 
Also,  the  physical  and  electrical  demarcation  point  between  the  user  device 
and  the  ATM  switch. 

•  Variable  Bit  Rate  (VBR)  A  type  of  traffic  that,  when  sent  over  a  network, 
is  tolerant  of  delays  and  changes  in  the  amount  of  bandwidth  it  is  allocated, 
(e.g.,  data  applications) 

•  Virtual  Channel  Connection  (VCC)  A  logical  communications  medium 
identified  by  a  VCI  and  carried  within  a  VPC.  VCCs  may  be  permanent  virtual 
channel  connections  (PVCCs),  switched  virtual  channel  connections  (SVCCs), 
or  smart  permanent  virtual  channel  connections  (SPVCC).  Further,  VCC  is  an 
end-to-end  logical  communications  medium.  Another  acronym,  VCL  (virtual 
channel  link),  is  more  precise,  referring  to  the  single  segment  object  identified 
by  a  VCI  and  carried  within  a  VPC.  Similarly,  a  VPC  is  an  end-to-end  object 
and  a  Virtual  Path  Link  (VPL)  is  identified  a  VPI  within  a  link. 

•  Virtual  Channel  Identifier  (VCI)  The  field  in  the  ATM  cell  header  that 
labels  (identifies)  a  particular  virtual  channel. 

•  Virtual  Circuit  (VC)  A  generic  term  for  any  logical  communications  medium. 
NOTE:  VC  does  not  stand  for  virtual  channel.   Virtual  channels  are  referred 
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to  as  VCCs  (virtual  channel  connections).    There  are  three  classes  of  VCs: 
permanent,  switched,  and  smart  (or  soft)  permanent. 

•  Virtual  Path  Connection  (VPC)  A  logical  communications  medium  in  ATM 
identified  by  a  virtual  path  identifier  (VPI)  and  carried  within  a  link.  VPCs 
may  be  permanent  virtual  path  connections  (PVPCs),  switched  virtual  path 
connections  (SVPCs),  or  smart  permanent  virtual  path  connections  (SPVPCs). 
VPCs  are  uni-directional. 

•  VTC  Video  Teleconferencing. 

•  Virtual  Path  Identifier  (VPI)  The  field  in  the  ATM  cell  header  that  labels 
(identifies)  a  particular  virtual  path. 

•  WIU  Wireless  Integrated  services  digital  network  interface  Unit. 

•  WFA  Warfighter  Associate. 
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APPENDIX  B.  PROTO  C  CODE  FOR  STATIC 
CHANNELS  DEFINITION  AND  ALLOCATION. 


/*  Read  the  channel  definition  file  and  define  static  channels    */ 
/*  for  the  ATM  switch.  */ 

void  load_static_channels_def inition(temp_atm_state_ptr) 
AtmT_ATM_State*  temp_atm_state_ptr ; 


AtmT_VP_Desc* 

temp_vp_ptr; 

AtmT_VC_Desc* 

temp_vc_ptr; 

AtmT_Port_Desc* 

temp_pdesc_ptr ; 

int 

MAX_CHANNELS  =  1024; 

int 

MAXSIZE  =  11; 

int 

total_ports; 

int 

port_count  =  0; 

int 

total_paths; 

int 

path_count  =  0; 

int 

total_channels  =  0; 

int 

vci_index  =  0; 

int 

channel_count  =  0; 

int 

value; 

int 

channel_array [1024] ; 

char 

string  [11]  ; 

FILE* 

input_f ile; 

FIN(load_static_channels_def inition(temp_atm_state_ptr)) ; 

/*  Open  the  channel  definition  file.  */ 

if  ( (input _f ile  =  f open("/usr/work/benton/input_channels" ,  "r")) 

==  NULL) 
{ 

ams_atm_mgmt_error( "Problem  opening  static  channel 

definition  file.",  0PC_NIL,  0PC_NIL) ; 
} 

/*  Read  the  first  line  to  get  the  number  of  requested  channels.  */ 

if   (fgets  (  string,  MAXSIZE,  input.file  )  !=  NULL) 

{ 

if  (LTRACE_STATIC_ACTIVE) 


135 


printf("In  load_static_channels  function;  string  is  \°/,s  .  "  , 
string) ; 
if  (get_digit (string,  &value)  ==  0PC_C0MPC0DE_FAILURE) 
{ 

ams.atm.mgmt.error  ("Invalid  number  of  static  channels.", 

OPC.NIL,  OPC.NIL); 

} 

total_channels  =  value; 

if  (LTRACE_STATIC_ACTIVE) 

{ 

printf ("In  load_static_channels  function  after  reading  ") ; 

printf ("channel  count ;total_channels  =  V/0d.", 
total_channels) ; 
} 


if  (total.channels  >  MAX.CHANNELS) 

{ 

ams_atm_mgmt_error( "Requested  virtual  channels  exceeds  allowed 

maximum.",  OPC.NIL,  OPC.NIL); 
} 

/*  Read  each  channel  definition  from  the  file  and  assign  the  */ 
/*  value  to  the  channel  array.  */ 

while  ((fgets  (  string,  MAXSIZE,  input.file  )  !=  NULL)  && 

(channel_count  <  total_channels)) 
{ 

if  (LTRACE_STATIC_ACTIVE) 
{ 

printf ("In  load_static_channels  function,  reading  each  ") ; 
printf  ("  channel;  channel_count  =  0/0d.",  channel_count)  ; 
printf  ("In  load_static_channels  function;  string  is  °/,s  .  "  , 
string) ; 
} 

if  (get .digit (string,  &value)  ==  OPC.COMPCODE.FAILURE) 
{ 

ams_atm_mgmt_ error  ("Invalid  number  for  static  channels.", 

OPC.NIL,  OPC.NIL); 
} 

if  (value  >  155000000) 
{ 
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ams_atm_mgmt_error  ("Exceeded  channel  capacity  in 

static  definition  file.",  OPC.NIL,  OPC.NIL) ; 
} 

channel_array [channel_count]  =  value; 
channel_count  =  channel_count  +  1; 

if  (LTRACE_STATIC_ACTIVE) 
{ 

printf("In  load_static_channels  function,  value  ") ; 

printf ("=  %d." ,   value); 


fclose(input_f ile) ; 

if  (LTRACE_STATIC_ACTIVE) 

{ 

printf  ("In  load_static_channels  function  after  closing  ") ; 
printf  ("file;  total.channels  =  0/0d.\n",  total_channels) ; 

} 

total_ports  =  temp_atm_state_ptr->port_data.port_count ; 

if  (LTRACE_STATIC_ACTIVE) 

{ 

printf ("In  load_static_channels  function;  ") ; 

printf  ("total_ports  =  Y/.d.",  total_ports)  ; 
} 

port_count  =  0; 

while  (port_count  <  total_ports) 

{ 

temp_pdesc_ptr  = 

&temp_atm_state_ptr->port_data.port_array [port_count] ; 
total_paths  =  temp_pdesc_ptr->vp_data. vp_count ; 

if  (LTRACE_STATIC_ACTIVE) 
{ 

printf ("In  load_static_channels  function;  ") ; 

printf  ("total_paths  =  °/0d.\n",  total_paths) ; 
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} 


path_count  =  0; 

while  (path_count  <  total_paths) 
{ 

temp_vp_ptr  = 

&temp_pdesc_ptr- >vp_data. vp_array [path_count] ; 

if    (temp_vp_ptr- >qos_desc. class  ==  3) 

{ 

ams_atm_vc_elements_add(temp_vp_ptr, 

total_channels) ; 

if  (LTRACE_STATIC_ACTIVE) 
{ 

printf("In  load_static_channels  function;  "); 

printf ("after  adding  channels  total_channels  = 
0/.d.\n",  total_channels)  ; 
} 

channel_count  =  0; 

while  (channel_count  <  total_channels) 
{ 

/*  Assign  the  requested  bandwidth  to  the  channel  */ 
temp_vp_ptr->vc_array 

[channel_count] . alloc_bandwidth_in 

=  channel_array [channel_count] ; 
t  emp_ vp_ptr->vc_array 

[channel_count] . alloc_bandwidth_out 

=  channel_array [channel_count] ; 
channel_count  =  channel_count  +  1; 
} 


path_count  =  path_count  +  1 ; 
} 
port_count  =  port_count  +  1; 
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/*  User  did  not  provide  the  correct  number  of  channel         */ 
/*  definitions.  */ 

if  (channel_count  !=  total_channels) 

{ 

ams_atm_mgmt_error  ("Did  not  define  correct  number  of 

channels",  OPC.NIL,  OPC.NIL); 
} 

FOUT; 


} 


/*  Verify  the  character  string  contains  only  numeric  digits  and    */ 
/*  then  convert  the  character  string  to  a  number.  */ 

Compcode  get_digit  (input_string,  value) 
char*  input_string; 
int*  value; 

{ 

#define  YES  1 
#define  NO   0 

char  ch; 

char  number [11] ; 

int  digit  =  YES; 

int  count  =  0 ; 

FIN  (get  .digit  (input  .'string,  value))  ; 

/*  Remove  the  newline  character  from  the  input  string  */ 

while  ( (ch=input_string [count] )  !=  '\n') 

{ 

number [count]  =  input_string [count] ; 

count  =  count  +  1 ; 
} 

number [count]    =    '\0'; 
count  =   0; 
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/*  Check  each  character  in  the  input  string  for  a  numeric  digit.   */ 
/*   If  any  character  fails  the  test,  set  the  flag  to  NO.  */ 

while  ((ch=number [count])  !=  '\0'  &&  digit  ==  YES) 

{ 

if  (lisdigit(ch)) 
{ 

digit  =  NO; 


count  =  count  +  1 ; 


/*  If  all  the  characters  were  numeric  digits,  then  convert  the  */ 
/*  string  to  a  number  and  return  SUCCESS.  Otherwise,  return  */ 
/*  FAILURE.  */ 

if  (digit  ==  YES) 
i 

♦value  =  atoi(input_string) ; 
if  (LTRACE_STATIC_ACTIVE) 

printf("In  get_digit;  value  =  Y/.d.",  *value) ; 

FRET(OPC_COMPCODE_SUCCESS) ; 
} 
else 

FRET(0PC_C0MPCODE_FAILURE) ; 


/*  This  function  finds  a  valid  vitrual  path  and  channel  given  a  */ 
/*  specific  atm  switch  and  port  via  atm_state_ptr  and  port_value.  */ 
/*  respectfully.  */ 

Compcode  ams_atm_avail_static_vp_vc_f ind  (atm_state_ptr, 

port.value,  vpi_value_ptr, 
vci_value_ptr, 
traf _con_ptr,  qos_class) 
AtmT_ATM_State*      atm_state_ptr; 
int  port_value; 

int*  vpi_value_ptr; 
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int*  vci_value_ptr; 

AmsT_Traf .Contract *  traf _con_ptr ; 
int  qos_class; 

AtmT_Port_Desc*  pdesc_ptr; 

AtmT_VP_Desc*  vp_ptr; 

AtmT_VC_Desc*  vc.ptr; 
int  vpi_index; 

int  vci_index; 

/*  This  procedure  finds  a  VPI  and  VCI  value  for  a  channel  in  */ 

/*  the  specified  direction  in  the  specified  port.   If  there  */ 

/*  is  no  VP  with  sufficient  available  bandwidth  and  correct  */ 

/*  Qos  class,  then  a  failure  status  is  returned;  otherwise,  */ 

/*  success.   No  state  information  is  modified  concerning  the  */ 

/*  VP  and  VCs.  */ 
FIN  (ams_atm_avail_static_vp_vc_f ind  (<args>)); 

/*  Obtain  the  port  desc  pointer.  */ 

pdesc.ptr  =  &atm_state_ptr->port_data.port_array  [port_value] ; 

/*  Loop  through  the  VPs  on  the  port  and  find  one  with         */ 
/*  sufficient  bandwidth.  */ 

for  (vpi_index  =  0;  vpi_index  <  pdesc_ptr->vp_data. vp.count ; 
vpi_index++) 

/*  Do  not  use  the  signalling  VP.-  */ 

if  (vpi_index  ==  AMSC_ATM_SIGVP_VPI) 
continue; 

/*  Obtain  the  vpi_index-th  in_VP  pointer.  */ 

vp_ptr  =  &pdesc_ptr->vp_data.vp_array  [vpi_index] ; 

/*  Determine  if  this  VP  has  the  correct  QoS  class.         */ 

if  (vp_ptr->qos_desc. class  !=  qos_class) 

{ 

/*  This  VP  does  not  support  the  requested  QoS  class;   */ 

/*  continue  to  the  next  VP.  */ 

vp_ptr  =  OPC.NIL; 

continue; 
}  /*  End  if  vp_ptr->qos_desc .class  !=  qos_class  */ 
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/*  Determine  if  this  VP  can  support  the  traffic.  */ 

if  (ams_atm_vp_supports_traff ic  (atm_state_ptr, 

port_value,  vpi_index, 
traf_con_ptr)  ==  0PC_TRUE) 

{ 

/*  This  VP  has  sufficient  bandwidth.  */ 

/*  Break  out  of  loop.  */ 

*vpi_value_ptr  =  vpi.index; 
break; 
}  /*  End  if  ams_atm_vp_supports_traff ic  */ 

/*  This  VP  has  insufficient  bandwidth.  Try  the  next  one.  */ 

/*  Set  the  pointer  to  NIL,  so  that  it  can  verified  if  the  */ 

/*  VP  search  failed.  */ 
vp_ptr  =  0PC_NIL; 

}  /*  End  for  loop  */ 

/*  If  the  VP  pointer  is  NIL,  then  the  search  failed.  */ 

/*  Handle  failure.  */ 

if  (vp.ptr  ==  OPC.NIL) 

{ 

FRET  (OPC_COMPCDDE_FAILURE) ; 
}  /*  End  if  vp_ptr  ==  0PC_NIL  */ 

/*  Found  an  available  VP  now  search  for  an  available  VC.       */ 
for  (vci_index  =  0;  vci_index  <  vp_ptr->vc_count ;  vci_index++) 
{ 

/*  Obtain  the  vci_index-th  in  VC  pointer.  */ 

vc_ptr  =  &vp_ptr->vc_array  [vci_index] ; 

/*  Determine  if  the  VC  is  free.  */ 

if  (vc_ptr->status  ==  AMSC_VC_FREE) 

{ 

/*  Determine  if  this  VC  can  support  the  traffic.       */ 
if  (ams_atm_vc_supports_traff ic  (atm_state_ptr , 

port_value,  vpi_index,  traf _con_ptr ,  vci_index) 

==  OPC.TRUE) 
{ 

/*  This  VP  has  sufficient  bandwidth.  */ 

/*  Break  out  of  loop.  */ 

*vpi_value_ptr  =  vpi_index; 
break; 
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}  /*  End  if  ams_atm_vc_supports_traff ic  */ 

}  /*  End  if  vc_ptr->status  ==  AMSC_VC_FREE 

/*  The  VC  is  in  use.   Set  the  pointer  to  NIL.  */ 

vc_ptr  =  OPC.NIL; 
} 

/*  If  the  VC  pointer  is  NIL,  then  the  search  failed.  */ 

/*  Handle  failure.  */ 

if  (vc.ptr  ==  OPC.NIL) 
{ 

FRET  (0PC_C0MPC0DE_FAILURE) ; 
} 
else 

{ 

FRET  (0PC_C0MPC0DE_SUCCESS) ; 

} 
}  /*  End  function  ams_atm_avail_static_vp_vc_f ind  */ 


/*  This  function  allocates  a  specific  port,  virtual  path  and      */ 
/*  virtual  channel  to  a  call.  */ 

AtmT_VC_Desc*  ams_atm_static_vp_vc_alloc  (atm_state_ptr , 

port_value,  vpi_value,  vci_value,  traf _con_ptr) 

AtmT_ATM_State*     atm_state_ptr; 

int  port_value; 

int  vpi_value; 

int  vci_value; 

AmsT.Traf .Contract*  traf _con_ptr ; 
{ 

AtmT_Port_Desc*     pdesc_ptr; 

AtmT_VP_Desc*       vp.ptr; 

AtmT_VC_Desc*       vc_ptr; 

int  vc_add_count ; 

/**  This  procedure  allocates  the  VPI  and  VCI  to  the  call  and    */ 

/**  adjusts  the  available  bandwidth  values.  The  pointer  to     */ 

/**  the  specified  VC  ds  is  returned.  */ 
FIN  (ams_atm_static_vp_vc_alloc  (<args>)); 
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/*  Verify  that  the  index  values  are  valid.  */ 

ams_atm_ st at ic_port_vp_vc_ verify  (atm_state_ptr, 

port_value,  vpi_value,  vci_value) ; 

/*  Obtain  pointers  to  the  port,  VP  and  VC  data  structures.      */ 
pdesc_ptr  =  &atm_state_ptr->port_data.port_array  [port_value] ; 
vp_ptr  =  &pdesc_ptr->vp_data. vp_array  [vpi_value] ; 
vc_ptr  =  &vp_ptr->vc_array  [vci_value]  ; 

/*  Verify  that  the  VC  is  not  in  use.  */ 

if  (vc_ptr->status  ==  AMSC_VC_IN_USE) 

ams_atm_ error  ("VC  is  already  in  use.   Unable  to  allocate  VC 
for  call.",  OPC.NIL,  OPC.NIL) ; 

/*  Set  VP's  fields.  */ 

vp_ptr->avail_bandwidth_in  -= 

traf _con_ptr->called_ctd . src_traf _desc . per  * 

AMSC_ATM_CELL_SIZE ; 
vp_ptr->avail_bandwidth_out  -= 

traf _con_ptr->calling_ctd . src_traf _desc . per  * 

AMSC_ATM_CELL_SIZE ; 
vp_ptr->avail_vc_count — ; 

/*  Set  VC's  fields.  */ 

vc_ptr->status  =  AMSC_VC_IN_USE; 

FRET  (vc_ptr) ; 
}/*  end  function  ams_atm_static_vp_vc_alloc  */ 


/*  This  function  will  verify  the  port_value,  vpi_value  and  */ 
/*  vci_value  are  all  valid  for  the  atm  switch  defined  by  the  */ 
/*  atm_state_ptr .  */ 

void  ams_atm_static_port_vp_vc_verify  (atm_state_ptr , 

port_value,  vpi_value,  vci_value) 
AtmT_ATM_State*  atm_state_ptr; 
int  port_value; 

int  vpi_value; 
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{ 


int  vci_value; 

AtmT_Port_Desc*  pdesc_ptr; 
AtmT_VP_Desc*    vp_ptr; 

char*  attempt _msg  =  "Attempted  to  determine  use  of 

VP/VC  on  port."; 

/**  This  procedure  verifies  that  the  port,  VPI,  and  VCI  values  */ 

/**  are  valid.   If  not,  then  an  error  message  is  displayed  and  */ 

/**  the  simulation  is  terminated.  */ 
FIN  (ams_atm_static_port_vp_vc_verify  (args)); 

if  (port_value  <  0) 
{ 

ams_atm_error  (attempt _msg,  "Port  value  provided  is  negative, 
which  is  not  a  valid  value.",  0PC_NIL) ; 
} 
else  if  (vpi_value  <  0) 

{ 

ams_atm_error  (attempt _msg,  "VPI  value  provided  is 

negative,  which  is  not  a  valid  value.",  0PC_NIL) ; 
} 
else  if  (vci_value  <  0) 

{ 

ams_atm_error  (attempt_msg,  "VCI  value  provided 

is  negative,  which  is  not  a  valid  value.", 
OPC.NIL); 
> 

if  (port_value  >=  atm_state_ptr->port_data.port_count) 

{ 

ams_atm_error  (attempt_msg,  "Port  value  provided  is  greater 
than  any  actual  port . " ,  OPC.NIL) ; 
} 
else 

pdesc_ptr  =  &atm_state_ptr->port_data.port_array 

[port_value]  ; 

if  (vpi_value  >=  pdesc_ptr->vp_data.vp_count) 

{ 

ams_atm_error  (attempt_msg,  "VPI  value  provided  is 

greater  than  any  actual  VPI  within  the  port.", 
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OPC_NIL) ; 

} 
else 

vp_ptr  =  &pdesc_ptr- >vp_data.vp_array   [vpi_value] ; 

if    (vci_value  >=  vp_ptr->vc_count) 

{ 

/*  The  requested  VC  is  greater  than  any  in  the  VP.  */ 

ams_atm_error  (attempt_msg,  "VCI  value  provided  is  greater 

than  any  actual  VCI  within  the  VPI . " , 

OPC.NIL) ; 


FOUT; 
}/*  end  function  ams_atm_static_port_vp_vc_verify  */ 


/*  This  function  verifies  the  virtual  channel  can  support  the      */ 
/*  required  traffic  load.  */ 

Boolean  ams_atm_vc_supports_traff ic  (atm_state_ptr ,  port_value, 

vpi_value,  traf _con_ptr,  vci_value) 
AtmT_ATM_State*      atm_state_ptr; 
int  port_value; 

int  vpi_value; 

int  vci.value; 

AmsT_Traf .Contract *  traf _con_ptr ; 

■c 

AtmT_Port_Desc*  pdesc_ptr; 

AtmT_VP_Desc*  vp_ptr; 

AtmT_VC_Desc*  vc_ptr; 

Boolean  support s_traf fie; 

double  in_pcr; 

double  out_pcr; 

/*  Determines  if  the  VC  can  accomodate  the  traffic  */ 

/*  requirements.   If  so,  OPC.TRUE  is  returned;  else,  OPC.FALSE  */ 
FIN  (ams_atm_vc_supports_traff ic  (<args>)); 

/*  Cache  the  incoming  and  outgoing  Peak  Cell  Rates  (PCRs)  as    */ 
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/*  defined  by  the  traffic  contract.  */ 

in_pcr     =  traf _con_ptr->called_ctd. src_traf _desc.pcr; 
out_pcr  =  traf _con_ptr->calling_ctd.src_traf _desc. per ; 

/*   Obtain  the  port,   VP  and  VC  data  structure  pointers.  */ 

pdesc_ptr  =  &atm_state_ptr->port_data.port_array   [port_value] ; 
vp_ptr  =  &pdesc_ptr->vp_data. vp_array   [vpi_value] ; 
vc_ptr  =  &vp_ptr->vc_array [vci_value] ; 

/*  If  the  rate  is  less  than  that  available  in  the  VC,  then  the  */ 
/*  VC   is   available.  */ 

if   ((vc_ptr->alloc_bandwidth_in  >   (in_pcr  * 

AMSC_ATM_CELL_SIZE))   &&    (vc_ptr->alloc_bandwidth_out 

>    (out.pcr  *   AMSC_ATM_CELL_SIZE))) 

{ 

/*  The  VC  meets  the  requirements.  */ 

support s_traf fie  =  OPC.TRUE; 
} 

else 
{ 

/*  The  VP/VC  does  not  meet  the  requirements.  */ 

support s.traf fie  =  OPC.FALSE; 
} 

FRET  (supports_traff ic) ; 
}  /*  end  function  ams_atm_vc_supports_traff ic  */ 
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APPENDIX  C.  BADD_CALL_REQUESTOR. 
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Process  Model  Report:  badd  callrequestor 

|  Tue  Jun  17  10:34:49  1997     |  Page  1  of  18 

External  File  Set 


attribute 


value 


type 


default  value 


external  file  set 


badd  functions 


typed  file 


Process  Model  Comments 


General  Process  Description: 

The  process  initiates  call  requests  and  sends  them  to  the 
badd_call_scheduler  module. 

ICI  Interfaces: 

badd_call_req_if_ici 

Packet  Formats: 

None. 

Statistic  Interfaces: 

None 

Process  Registry: 


Published  Attributes:  None 
Expected  Attributes:  None 

Restrictions: 

None 


Process  Model  Attributes 

Attribute  interarrivai  time  properties 

Property 

Value 

Default  Value: 

0.001 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Units: 

seconds 

Low  Range: 

0.0  exclusive 

Comments: 

Specifies  the  interarrivai 
time  between  packets. 

Attribute  packet  size 

properties 

Property 

Value 

Default  Value: 

1000 

Data  Type: 

integer 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 
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Units: 

bits 

Comments: 

Specifies  the  size  of  the 
packets  generated  (in  bits). 

Attribute  call  wait  time  properties 

Property 

Value 

Default  Value: 

10 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Units: 

seconds 

Low  Range: 

0.0  exclusive 

Comments: 

Specifies  the  time  between 
calls. 

Attribute  call  duration  properties 

Property 

Value 

Default  Value: 

1,000 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Units: 

seconds 

Low  Range: 

0.0  exclusive 

Comments: 

Specifies  the  length  of  a 
call. 

Attribute  dest  addr  properties 

Property 

Value 

Default  Value: 

NONE 

Data  Type: 

integer 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Specifies  the  destination  of 
the  call. 

Symbol  Map: 

Symbol 

Value 

NONE 

-1 

Allow  other  values: 

YES 

Attribute  AAL  type  properties 

Property 

Value 

Default  Value: 

5 

Data  Type: 

integer 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Specifies  the  AAL  type  to  be 
used. 

Symbol  Map: 

Symbol 
1 

Value 
i 

i 
2 

1 

2 

34 

34 
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5 

5 

Allow  other  values: 

NO 

Attribute  QoS  class  properties 

Property 

Value 

Default  Value: 

D 

Data  Type: 

string 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Specifies  the  QoS  class. 

Symbol  Map: 

Symbol 

Value 

A 

A 

B 

B 

C 

C 

D 

D 

Allow  other  values: 

NO 

Process  Model  Interface  Attributes 

Attribute  begsim  intrpt  properties 

Property 

Value                                                                   Inherit 

Assign  Status: 

hidden 

Initial  Value: 

enabled                                                                  N/A 

Default  Value: 

disabled                                                                  YES 

Data  Type: 

toggle                                                                   N/A 

Attribute  Description: 

Private                                                                 N/A 

Comments: 

YES 

This  attribute  specifies  whether  a  'begin  simulation 

interrupt'  is  generated  for  a  processor  module's  root 

process  at  the  start  of  the  simulation. 

Symbol  Map: 

NONE                                                                     YES 

Attribute  endsim  intrpt  properties 

Property 

Value                                                                   Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled                                                                  N/A 

Default  Value: 

disabled                                                                  YES 

Data  Type: 

toggle                                                                      N/A 

Attribute  Description: 

Private                                                                    N/A 

Comments: 

YES 

This  attribute  specifies  whether  an  'end  simulation 

interrupt'  is  generated  for  a  processor  module's  root 

process  at  the  end  of  the  simulation. 

Symbol  Map: 

NONE                                                                     YES 

Attribute  failure  intrpts  properties 

Property 

Value                                                                      Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled                                                                  N/A 
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Default  Value: 

disabled 

YES 

Data  Type: 

enumerated 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  failure  interrupts 

are  generated  for  a  processor  module's  root  process 

upon  failure  of  nodes  or  links  in 

the  network  model. 

Symbol  Map: 

NONE 

YES 

Attribute  intrpt  interval  properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle  double 

N/A 

Attribute  Description: 

Private 

N/A 

Units: 

sec. 

YES 

Comments: 

YES 

This  attribute  specifies  how  often  regular  interrupts 

are  scheduled  for  the  root  process  of  a  processor  module. 

Symbol  Map: 

NONE 

YES 

Attribute  priority  properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

0 

N/A 

Default  Value: 

0 

YES 

Data  Type: 

integer 

N/A 

Attribute  Description: 

Private 

N/A 

Low  Range: 

-32767  inclusive 

YES 

High  Range: 

32767  inclusive 

YES 

Comments: 

" 

YES 

This  attribute  is  used  to  determine  the  execution  order 

of  events  that  are  scheduled  to 

occur  at  the  same 

simulation  time. 

Symbol  Map: 

NONE 

YES 

Attribute  recovery  intrpts  properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

enumerated 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether 

recovery  interrupts 

are  scheduled  for  the  processor 

module's  root  process 

upon  recovery  of  nodes  or  links 

in  the  network  model. 

Symbol  Map: 

NONE 

YES 
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Attribute  super  priority  properties 
Property 

Value 

Inherit 

Assign  Status: 
Initial  Value: 

hidden 
disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 
Attribute  Description: 
Comments: 

toggle 
Private 

N/A 
N/A 
YES 

This  attribute  is  u 

sed  to  determi 

ne 

the  execution  order 

of  events  that  are 

schedi 

jled  to 

occur 

at  the 

same 

simulation  time. 

Symbol  Map: 

NONE 

YES 

Process  Model  Simulation  Attributes 

Attribute  class_A_CDV_ 

tolerance 

properties 
Value 

Property 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 
variance  that  two 
consecutive  Quality  of 
Service  (QoS)  class  A  cells 
may  experience. 

Attribute  class  B  CDV 

tolerance 

properties 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 
variance  that  two 
consecutive  Quality  of 
Service  (QoS)  class  B  cells 
may  experience. 

Attribute  class  C  CDV 

tolerance  properties 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 
variance  that  two 
consecutive  Quality  of 
Service  (QoS)  class  C  cells 
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may  experience. 

Attribute  class_D_CDV_tolerance  properties 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 

variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  D  cells 

may  experience. 

Header  Block 


10 


15 


20 


25 


30 


35 


#include  "  /usr/local/mil3_dir/3  .0  .A_DL5 /models /std/atm/ams_inter faces  .h" 

#include  ■  /usr/local/mil3_dir/3  .0  . A_DL5 /model s/std /at m/ams_aal_inter faces  .h" 

/*  Code  added  for  badd  *l 

#include  "  /usr/wor)c/benton/op_code/badd_interf  ace  .h" 

/*  end  code  added  for  badd  */ 


I*  These  are  transition  conditions.  */ 
#defme  SIGNAL 


#define  EST_CON 
#define  REL_IND 
#defme  REL_CON 
#defme  CALL_START 

#define  CALL_END 


((op_intrpt_type  ()  =  OPCJNTRPT_REMOTE)  &&       \ 
(op_intrpt_code  ()  =  AMSC_INTERFACE_SIGNAL)) 

(SIGNAL  &&  (primitive  =  AMSC_AAL_ESTAB_Con)) 

(SIGNAL  &&  (primitive  =  AMSC_AAL_RELEASE_Ind)) 

(SIGNAL  &&  (primitive  =  AMSC_AAL_RELEASE_Con)) 

((op_intrpt_type  ()  =  OPC_INTRPT_SELF)  &&  \ 

(op_intrpt_code  ()  =  AMSC_TGEN_CALL_START)) 

((opintrpttype  ()  =  OPC_INTRPT_SELF)  &&  \ 

(op_intrpt_code  ()  =  AMSC_TGEN_CALL_END)) 


#defme  NEIGHBOR_NOTIFY      ((opintrpttype  ()  =  OPC_INTRPT_REMOTE)  &&       \ 

(opintrptcode  ()  =  AMSC_NEIGHBOR_NOTEFY)) 

ffdeHne  NOTIFY_COMPLETE     (ams_neighbor_notify_is_complete  (nbr_data_ptr)  =  OPC_TRUE) 

/*  Code  added  for  badd  *l 

#define  WAjT_CALL_DURATION    ((op_intrpt_type  ()  ==  OPC_INTRPT_SELF)  &&  \ 

(op_intrpt_code  ()  =  AMSC_TGEN_WAIT_CALL_DURATION)) 

/*  End  code  added  for  badd  *l 

I*  These  are  the  ams_lraf_gen  self  interrupt  codes.  */ 

#deHne    AMSC_TGEN_CALL_START      0 

#define  AMSC_TGEN_CALL_END     1 

#define  AMSC_TGEN_DATA_GEN    2 

I"  Code  added  for  badd  *l 

#defme  AMSC_TGEN_WAIT_CALL_DURATION     3 

f*  End  code  added  for  badd  */ 
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40 


45 


50 


55 


60 


65 


/*  The  ams_traf_gen  process  will  output  trace  information  if  this  conditional  is  true.  */ 
#defme  LTRACE_ ACTIVE  (debug_mode  &&  \ 

(op_prg_odb_ltrace_acti ve  ( ■  ams " )  II  \ 

op_prg_odb_ltrace_active  ("ams_traf ")  II  \ 

op_prg_odb_ltrace_acti ve  ( " ams_t  ra  t _gen " ))) 

#defiDe  LTRACE_CONNECT_ACTIVE      (opprgodbltraceactive  ( -connect  ■)) 

/*  Code  added  for  badd  *l 

#define  LTRACE_CALL_REQUESTOR_ACTIVE     (op_prg_odb_ltrace_active  ( -cal  l_requestor")) 

/*  Procedure  declarations.  *l 

void  badd_call_req_nbr_intrpt_proc  (); 

void  badd_call_req_spurious_signal_handle  (); 

void  badd_call_req_error  (); 


State  Variable  Block" 


10 


15 


20 


25 


int 

\debug_mode; 

int 

\packet_size; 

Distribution* 

\int_arri  val_di  stptr; 

Distribution* 

\call_wait_distptr; 

Distribution* 

\call_duration_distptr; 

double 

\avg_rate; 

Objid 

\aal_module_id; 

Ici* 

Saal_handle_iciptr; 

Evhandle 

\next_packet_arri  val ; 

Evhandle 

\call_end_intrpt; 

int 

\dest_addr; 

char 

\pid_string[128]; 

int 

\to_aal_stream_index; 

Objid 

\my_id; 

int 

\AAL_type; 

int 

\qos_dass; 

AmsT_Traf_Contract*    \traf_con_ptr; 
AmsT_Neighbor_Data*  \nbr_data_ptr, 

/*  Code  added  for  badd  *l 


double 

\int_arr_ttme; 

double 

\call_wait_time; 

double 

\call_duration; 

Objid 

\sch_module_id; 

int 

Nto_sch_stream_index; 

Badd  Sch 

_Mod_Data     \Scheduler_Module 

Badd_Sch. 

.Call_Desc    \Scheduler_Call; 
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/*  End  code  added  for  badd  *l 


Temporary  Variable  Block 

int                                    primitive; 

Packet*                           pkptr. 

Ici*                                 if_iciptr; 

AmsT_Traf_Contract*    tmp_traf_con_ptr; 

5 

double                             peak_cell_rate; 

char                                 qos_class_string  [128]; 

double                              cdv_tolerance; 

/*  Code  added  for  badd  *l 

10 

int                                    cd_packet_size; 

int                                   clark_dest_addr. 

double              badd_packet_size; 

double        "                     event_time; 

double                             end_sim_time; 

15 

extern  int                        total_calls_requested; 

Prohandle           call_gen_prohandle; 

/*  End  code  added  for  badd  *l 

20 

Function  Block 


10 


15 


20 


25 


void 

badd_call_req_nbr_intrpt_proc  (ndata_ptr,  ndesc_ptr,  state_ptr) 

AmsT_Neighbor_Data*  ndata_ptr; 

AmsT_Neighbor_Desc*  ndesc_ptr, 

void*  state_ptr; 


AmsT_Neighbor_Verify_Desc 
int 


vdesc; 
to_sw_stream_index; 


/**  This  procedure  handles  a  neighbor  notification  event  in  an  AMS 
/**  trafgen  specific  manner.  It  determines  the  neighbor' s  object 
I**  ID  and  type,  and  verifies  that  there  are  a  correct  number  of 
/**  interconnections. 
FIN  (badd_calI_req_nbr_intrpt_proc  (ndata_ptr,  ndesc_ptr,  state_ptr)); 

/*  Switch  based  on  the  AMS  type. 
switch  (ndesc_ptr->module_amstype) 

{ 

case  AMSC_MTYPE_AAL_CLIENT: 

( 

/*  Build  the  verify  desc  data  structure. 


**/ 
**/ 
**/ 
**/ 


*/ 


vdesc.modjd 

vdesc.nbr_id 

vdesc.nbr_id_ptr 

vdesc.mod_name 

vdesc.nbr_name 

vdesc.nbr_type 


=  my_id; 

=  ndesc_ptr->module_objid; 

=  &sch_module_id; 

=  "BADD   Call    Requestor"; 

=  "call_sch"; 

=  AMSC  MTYPE  AALJXENT; 
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30 


35 


40 


45 


50 


55 


60 


65 


70 


75 


80 


85 


vdesc.fr  om_nbr_strm_cnt 
vdesc.from_nbr_strm_index_ptr 
vdesc.to_nbr_strm_cnt 
vdesc.to_nbr_strm_index_ptr 


=  1; 

=  OPC_NIL; 

=  1; 

=  &to  sch  stream  index; 


/*  Verify  that  the  neighbor  has  the  correct 
I*  characteristics. 
ams_neighbor_verify  (&vdesc); 

break; 


default: 


/*  This  is  an  unexpected  neighbor  notification.  *l 

I*  Issue  error  message.  *l 

op_sim_end  ( ■  Process    received  a   neighbor  notification   from  a  module", 

"of   an   unexpected   type.      Simulation   terminated.  ",  OPC_NIL,  OPC_NIL); 

break; 


FOUT; 


void 
badd_call_req_spurious_signaJ_handle  () 

{ 

Ici*  if_iciptr; 

Ici*  release_if_iciptr; 

int  primitive; 

Ici*  ll_handle_iciptr. 

Packet*  pkptr, 

/*  This  procedure  handles  spurious  interrupts. 

I*  Only  three  types  of  spurious  interrupts  can  be  accepted.  All 

I*  others  must  result  in  an  op_sim_end  ().  These  three 

/*  interrupts  are: 

I*      I.  An  AAL  ESTAB  Ind. 

/*      2.  An  AAL  RELEASE  Con. 

I*      3.  A  packet  arrival. 

FEN  (badd_call_req_spurious_signal_handle  ()); 

if  (SIGNAL) 
( 
/*  This  is  a  signal  from  the  AAL. 

I*  Obtain  the  ICI  pointer. 
ifjciptr  =  op_intrpt_ici  (); 

/*  Obtain  the  primitive  from  the  ICI. 

op_ici_attr_get  (if_iciptr,  "pr imit  ive ",  &primitive); 

I*  Obtain  the  'lower  layer  handle'  from  the  ICI. 

op_ici_attr_get  (ifjciptr,  "lower   layer  handle",  &ll_handle_iciptr); 

"  Switch  on  the  'primitive' .  *l 

switch  (primitive) 


*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
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90 


95 


100 


105 


110 


115 


120 


125 


130 


135 


140 


145 


{ 

case  AMSC_AAL_ESTAB_lnd: 

( 

/*  This  is  an  'establish  indication'  from  the  AAL.  *l 

if(LTRACE_ACTIVE) 

{ 

op_prg_odb_print_major  (pid_string,  "Received  spurious  AAL   ESTABLISH   Request    signal.", 

"Call   not    accepted.  ",  "Sending  AAL   RELEASE  Request    signal  .",  OPC_NIL); 
) 

/*  Set  the  '  upper  layer  handle'  in  the  interface  *l 

I*  IC1  for  the  'establish  indication  signal,  since  */ 

I*  the  lower  layer  expects  it  to  be  filled  in.  The  *l 

I*  ICI  is  not  destroyed,  since  this  is  a  forced  *l 

I*  interrupt  and  the  lower  layer  process  expects  */ 

/*  to  obtain  the  handle  from  the  ICI  when  the  *l 

I*  control  returns.  *I 
op_ici_attr_set  (if_iciptr,  "upper  layer  handle",  OPC_NIL); 

/*  Simply  send  an  AAL_RELEASE_Req  to  request  that  *l 

I*  the  connection  be  released.  *l 

release_if_iciptr  =  opjcicreate  (AMSC_INTERFACE_ICI); 
op_ici_attr_set  (release_if_iciptr,  "primitive",  AMSC_AAL_RELEASE_Req); 
op_ici_attr_set  (release_if_iciptr,  "lower   layer  handle",  ll_handle_iciptr); 
opiciinstall  (release_if_iciptr); 

/*  Send  a  remote  interrupt  which  will  carry  the  ICI  to  the  AAL  module.  */ 
op_intrpt_schedule_remote  (opsimjime  (),  AMSC_INTERFACE_SIGNAL,  aal_module_id); 

break; 

} 

case  AMSC_AAL_RELEASE_Con: 

{ 

/*  This  is  a  'release  confirm'  from  the  AAL.  *l 

if(LTRACE_ACTIVE) 

{ 

op_prg_odb_print_major  (pid_string,  "Received  spurious   AAL  RELEASE  Confirm  signal.", 
"This    is   in   response  to  AAL   RELEASE  Request   terminating  spurious   connection. 


) 


/*  This  is  a  response  to  our  earlier  '  release 
I*  request'  which  was  a  response  to  the 
I*  spurious  '  estab  indication' . 
I*  Do  nothing  other  than  destroy  the  ICI. 
op_ici_destroy  (ifjciptr); 

break; 

} 


*/ 
*/ 
*/ 
*/ 


default: 


/*  This  is  some  other  completely  unexpected 

I*  signal.  Issue  error  message  and  terminate 

I*  simulation. 

op_sim_end  ( "Received  unexpected   signal.", 


*/ 

*/ 
*/ 


■,-"): 
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) 
) 
else  if  (opjntrptjype  ()  =  OPC_INTRPT_STRM) 

150 

i 

/*  This  is  a  spurious  packet  arrival.  The  ams  traf  gen                                   *l 

1*  just  destroys  this  packet.                                                                              *l 

if(LTRACE_ACTIVE) 

I 

155 

i 

op_prg_odb_print_major  (pid_string,  "Received  spurious  DATA  packet.", 

"Destroying  the  packet .",  OPC_NIL); 
} 

160 

/*  Get  the  packet  fromt  the  stream  and  destroy  it.                                          */ 
pkptr  =  op_pk_get  (op_intrpt_strm  ()); 
op_pk_destroy  (pkptr); 

X 

) 
else 

165 

( 

/*  This  is  some  other  completely  unexpected                                          *l 
1*  interrupt.  Issue  error  message  and  terminate                                    *l 
1*  simulation.                                                                                           *l 

op  sim  end  ("Received   unexpected    interrupt.","","",""); 
) 

170 

FOUT; 

} 

175 

void 

badd_call_req_error  (msgO,  msgl,  msg2) 

char*               msgO; 

char*               msgl; 

char*              msg2; 

180 

( 

/**  Print  an  error  message  and  exit  the  simulation.  **/ 

FIN  (badd_call_reg_error  (msgO,  msgl,  msg2)); 

op  sim  end("Error   in  badd_call_requestor  process:", 
msgO,  msgl,  msg2); 

185 

FOUT; 

} 

Diagnostic  Block 


/*  Display  connection  information,  if  requested.  */ 
if  (LTRACE_CONNECT_ACTrVE) 

{ 

/*  Print  information.  *l 

ams_neighbor_data_print  (nbr_dala_ptr,  ams_neighbor_desc_print_noop); 
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forced  state    INIT 

attribute 

value 

tvpe 

default  value 

name 

enter  execs 
exit  execs 
status 

INIT 

(See  below.) 

(empty) 

forced 

string 
textlist 
textlist 
toggle 

st 

(empty) 
unforced 

enter  execs    INIT 


10 


15 


20 


25 


30 


35 


40 


45 


/*  Determine  the  initial  values  of  the  state  variables  and  set  up  *l 

I*  the  initial  stale  of  this  instantiation  of  the  amsjrafgen  */ 

/*  process.  */ 

/*  Obtain  the  object  ID  of  this  process'  parent  module.  *l 

my_id  =  op_id_self  (); 

/*  Obtain  the  attribute  values  for  the  packet  interarrival  *l 

I*  time,  size,  wait  time  between  calls,  call  duration,  and  *l 

/*  destination  address.  These  values  are  process  attributes.  */ 

op_ima_obj_attr_get  (my_id,  "interarrival   t  ime  ■ ,  &int_air_time); 
op_ima_obj_attr^get  (my_id,  "  packet   size",  &packet_size); 
op_ima_obj_attr_get  (my_id,  "call  wait   time",  &call_wait_time); 
op_ima_obj_attr_get  (my_id,  "call   durat  ion " ,  &caIl_duration); 
op_ima_obj_attr_get  (my_id,  "dest   addr",  &dest_addr); 
op_ima_obj_attr_get  (my_id,  ■  QoS  class",  qos_class_string); 
op_ima_obj_attr_get  (my_id,  "AAL  type " ,  &AAL_type  ); 

/*  Convert  the  Quality  of  Service  class  character  into  *l 

I*  the  index  value  and  check  its  validity.  */ 

ams_qos_class_char_to_index_convert  (qos_class_string  [0],  &qos_class); 
if  (qos_class  =  AMSC_QOS_CLASS_UNDEF) 

{ 

/*  The  QoS  Class  value  is  invalid.  Issue  error  message  *l 

I*  and  terminate  the  simulation.  *l 

op_sim_end  ("Specif  ied  Quality  of  Service  Class  attribute  value  is  invalid. 

"Value  must  be  'A',  'B',  'C,  or  '  D'  .",""," "); 
} 

/*  Load  in  the  call  wait  distribution  *l 

call_wait_distptr  =  op_dist_load( " constant " ,  call_wait_tinie,  0.0); 

caJl_duration_distptr  =  op_dist_load  ("constant ",  call_duration,  0.0); 

/*  determine  whether  or  not  the  simulation  is  in  debug  mode.  *l 

debug_mode  =  op_sim_debug  (); 

/*  Initialize  the  AAL  module  object  ID  to  NULL  value.  */ 

aal_module_id  =  OPC_OBJID_NULL; 
sch_module_id  =  OPC_OBJID_NULL; 

/*  Generate  PID  display  siring.  *l 

sprintf  (pid_string,  "badd_call_requestor   PID    (%d)  ",  op_pro_id  (op_pro_self  ())); 


/*  Obtain  and  send  out  neighbor  information. 
nbr_data_ptr  =  ams_neighbor_data_biiild  (); 

ams_neighbor_notify  (nbr_data_ptr,  BADD_MTYPE_SCHEDULER_CLEENT); 


*/ 
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50 


55 


60 


/*  Code  added  by  BADD  */ 

if  (LTRACE.C  ALL_REQUESTOR_ACTIVE) 

{ 

printf("In   badd_call_requestor .  init :    printing  badd_cal  l_requestor  neighbor    info.Xn"); 
/*     ams _neighbor _dala_prinl  (nbr_data_plr,  amsjieighbor  _desc_prinl_noop); 
I*     badd_call_req  error  ("In  badd_call  requestor  .init:  ending  simulation  test\n");  */ 
}  I*  End  if(LTRACE_CALL_REQUESTOR_ACTIVE)  */ 

if  (LTRACE_CALL_REQUESTOR_ACTIVE) 
{ 

printf("In   badd_ca  1  l_requestor .  init    state:    Leaving    init    state.    \n"); 


/*  End  code  added  for  BADD  *l 


transition     INIT 

->  confiq 

attribute 

value 

tvoe 

default  value 

name 

tr  1 

string 

tr 

condition 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

line 

toggle 

spline 

unforced  state    confiq 

attribute 

value 

tvoe 

default  value 

name 

enter  execs 
exit  execs 
status 

config 
(empty) 
(See  below.) 
unforced 

string 
textlist 
textlist 
toggle 

St 

(empty) 
unforced 

exit  execs    confiq 

/*  Ams  traf  gen  expects  either  a  neighbor  notification  interrupt,                                 *l 

1*  or  a  spurious  signal.                                                                                                    */ 

if  (NEIGHBOR_NOTIFY) 

5 

1 

/*  This  is  a  'neighbor  notify'  signal.                                                                       *l 

if  (LTRACE_  ACTIVE) 

l 

op_prg_odb_print_major  (pid_string,  "Received  neighbor   not  if  ication  .  ",  OPC_NIL); 

10 

1 

1*  Handle  the  neighbor  notification.                                                                       *l 

ams_neighbor_interrupt_handle  (nbr_data_ptr,  badd_call_req_nbr_intrpt_proc,  OPC_NIL); 

] 

J 
else 

15 

{ 

/*  This  is  a  spurious  interrupt.  Handle  appropriately.                                          */ 
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badd_call_req_spurious_signal_handle(); 


transition    confiq 

■>  confiq 

attribute 

value 

tvpe 

default  value 

name 

tr  0 

string 

tr 

condition 

default 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

spline 

toggle 

spline 

transition    confiq  ->  schedule 

attribute 

value 

tvpe 

default  value 

name 

tr  2 

string 

tr 

condition 

NOTIFY  COMPLETE 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

spline 

toggle 

spline 

forced  state    schedule 


attribute 


value 


type 


default  value 


name 

enter  execs 
exit  execs 
status 


schedule 
(See  below.) 
(empty) 
forced 


string 
textlist 
textlist 
toggle 


st 

(empty) 
unforced 


enter  execs    schedule 


10 


15 


I*  Code  added  for  BADD  */ 

event_time  =  op_sim_time()  +  op^dis^outcome  (call_wait_distptr); 

if  (LTRACE_CALL_REQUESTOR_ACTIVE) 

{ 

printf ( "  I  n  clark_badd_cal l_requestor .schedule;  schedule  start  for  %f.\n" 
event_time); 

} 

/*  End  code  added  for  BADD  *l 

I*  Start  call  by  scheduling  selfintrpt.  *l 

opintrptscheduleself  (event_time,  AMSC_TGEN_CALL_START); 
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transition    schedule 

->  wait 

call 

idle 

attribute 

value 

tvoe 

default  value 

name 

tr  3 

string 

tr 

condition 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

line 

toggle 

spline 

unforced  state    wait  call  idle 


attribute 


value 


type 


default  value 


name 

enter  execs 
exit  execs 
status 


wait_call_idle 
(empty) 
(See  below.) 
unforced 


string 
textlist 
textlist 
toggle 


st 
(empty) 

unforced 


exit  execs    wait  call  idle 

/*  Ams  traf  gen  expects  two  interrupts: 

*/ 

l*l.A  self  interrupt  that  signals  a  new  call. 

*/ 

1*  2.  A  spurious  interrupt. 

*/ 

5 

/*  If  this  is  not  a  call  start  handle  the  spurious  interrupt; 

*/ 

/*  otherwise,  the  transition  conditions  will  cause  the  process  to 

*/ 

1*  go  to  the  'start'  state. 

*/ 

if(!CALL_START) 

f 

10 

/*  This  is  a  spurious  interrupt.  *l 

badd_call_req_spurious_signal_haridle  (); 
) 

transition     wait 

call 

idle 

->  watt 

call 

idle 

., 

. 

tvpe 

default  value 

attribute 

value 

name 
condition 
executive 
color 
drawing  style 

tr_4 
default 

RGB333 
spline 

string 
string 
string 
color 
toggle 

tr 

RGB333 
spline 

transition     wait 

call 

idie 

->  start 

attribute 

value 

type 

default  value 

name 

tr  102 

string 

tr 

condition 

CALL  START 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

spline 

toggle 

spline 
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forced  state    start 


attribute 


value 


type 


default  value 


name 

enter  execs 
exit  execs 
status 


start 

(See  below.) 

(empty) 

forced 


string 
textlist 
textlist 
toggle 


st 

(empty) 
unforced 


enter  execs    start 


10 


15 


20 


25 


30 


35 


40 


45 


/*  Start  a  call  by  issuing  a  call  open  request  to  the  ATM  */ 

/*  adaptation  layer.  *l 

if(LTRACE_ACTIVE) 

{ 

op_prg_odb_print_major(pid_string,  "  Initiating  call  Request.", 

"Sending  Request  signal  to  Call  Scheduler .",  OPC_NIL); 

} 


/*  Code  added  by  Clark  *l 

if  (LTRACE_CALL_REQUESTOR_ACTIVE) 

( 

printf("In   badd_call_requestor,    start;    reached   start    state.  \n"); 
)  /*  if(LTRACE_CALLREQUESTOR_ACTIVE)*l 

I*  Create  and  set  the  fields  in  the  interface  ICI.  *l 

if_iciptr  =  op_ici_create  ("badd_call_req_if_ici  *); 

/*  Code  commented  out  for  badd  testing  */ 
op_ici_install  (if_iciptr); 

/*  End  commented  out  code  */ 

badd_packet_size  =  packet_size; 

/*  Compute  the  peak  cell  rate  in  cells/second,  which  is  set  to  1  */ 

/*  times  the  average  cell  rate  in  this  example.  *l 

peak_cell_rate  =  ( 1.0  /  int_an_time)  *  (badd_packet_size  /  AMSC_ATM_CELL_DATA_SIZE); 


op_ici_attr_set  (if_ 
op_ici_attr_set  (if 
op_ici_attr_set  (if_ 
op_ici_attr_set  (if_ 
op_ici_attr_set  (if. 
op_ici_attr_set  (if 
op_ici_attr_set  (if. 
op_ici_attr_set  (if_i 


ciptr,  "interarrival   time",  int_arr_time); 
ciptr,  "packet  size",  packet_size); 
ciptr,  "call   wait  t  ime " ,  call_wait_time); 
ciptr,  "call   duration",  call_duration); 
ciptr,  "dest  addr",  dest_addr); 
ciptr,  "QoS   class",  qos_class); 
ciptr,  "AAL  type",  AAL_type); 
ciptr,  "peak  cell    rate",  peak_cell_rate); 


/*  Code  added  by  Clark  *l 

if  (LTRACE_CALL_REQUESTOR_ACTI  VE) 

{ 
printf("In  badd_call_requestor,    start;    starting  call   to  dest    %d.\n", 
dest_addr); 
)  /*  if(LTRACE_CALLREQUESTOR_ACTIVE)rl 

I*  End  of  code  added  by  Clark  *l 

I*  Send  a  remote  interrupt  which  will  carry  the  ICI  to  the  AAL  */ 
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50 


55 


60 


65 


/*  module.  */ 

/*  Code  commented  out  for  badd  testing  *l 

op_intrpt_schedule_remote  (op_sim_time  (),  BADD_REQUEST_SIGNAL,  sch_module_id); 

/*  End  commented  out  code  */ 

/*  Generate  a  self  intrpt  to  wake  up  this  process  for  generating   *l 
I*  another  call  request.  *l 

if  (LTTIACE.CALL.REQUESTOR.ACTIVE) 
{ 

event_time  =  op_sim_time()  +  op_dist_outcome  (call_duralion_distptr); 

printf("In   clark_badd_cal l_requestor . start ;    schedule   call    completion    for   %f.\n" 
event_time); 


op_intrpt_schedule_self  (op_sim_time  ()  + 

op_dist_outcome  (call_duration_distptr),  AMSC_TGEN_WAIT_CALL_DURATION); 


transition    Start 

->  wait 

call 

duration 

attribute 

value 

tvoe 

default  value 

name 

tr  105 

string 

tr 

condition 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

spline 

toggle 

spline 

unforced  state    wait  call  duration 

attribute 

value 

tvpe 

default  value 

name 

enter  execs 
exit  execs 
status 

wait_call_duration 
(empty) 
(See  below.) 
unforced 

string 
textlist 
textlist 
toggle 

st 
(empty) 

unforced 

exit  execs    wait  call  duration 

/*  wait  call  duration  expects  two  interrupts: 

*/ 

1*  LA  self  interrupt  that  signals  expired  call  duration  time. 

*/ 

1*2.  A  spurious  interrupt. 

*/ 

5 

1*  If  this  is  not  a  call  start  handle  the  spurious  interrupt; 

*/ 

1*  otherwise,  the  transition  conditions  will  cause  the  process  to 

*/ 

1*  go  to  the  'start'  stale. 

*/ 

if  (!  WAIT_CALL_DURATION) 

10 

/*  This  is  a  spurious  interrupt.  *l 

badd_call_req_spurious_signal_handle  (); 

} 
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transition    wait 

call 

duration 

->  wait 

call  duration 

attribute 

value 

tvpe 

default  value 

name 

tr  96 

string 

tr 

condition 

default 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

spline 

toggle 

spline 

transition    wait 

call 

duration 

i_  j  i 

->  schedule 

attribute 

value 

tvpe 

default  value 

name 

tr  100 

string 

tr 

condition 

WAIT  CALL  DURATION 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

spline 

toggle 

spline 
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External  File  Set 

attribute 

i 

. 

default  value 

value 

tvpe 

external  file  set 

badd  functions 

typed  file 

Process  Model  Comments 


General  Process  Description: 

The  ams_traf_gen  process  initiates  call  start  and  end,  generates  the 
actual  packets,  and  sends  them  to  the  AAL  module.  It  provides  an  example 
of  an  AAL  client  process. 

ICI  Interfaces: 

ams_if_ici 

Packet  Formats: 

None. 

Statistic  Interlaces: 

None 

Process  Registry: 


Published  Attributes:  None 
Expected  Attributes:  None 

Restrictions: 

None 


Process  Model  Interface  Attributes 

Attribute  begsim  intrpt  properties 

Property 

Value                                                                      Inherit 

Assign  Status: 

hidden 

Initial  Value: 

enabled                                                                   N/A 

Default  Value: 

disabled                                                                  YES 

Data  Type: 

toggle                                                                      N/A 

Attribute  Description: 

Private                                                                 N/A 

Comments: 

YES 

This  attribute  specifies  whether  a  'begin  simulation 

interrupt'  is  generated  for  a  processor  module's  root 

process  at  the  start  of  the  simulation. 

Symbol  Map: 

NONE                                                                     YES 

Attribute  endsim  intrpt  properties 

Property 

Value                                                                      Inherit 

Assign  Status: 

hidden 
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Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  an  'end  simulation 

interrupt'  is  generated  for  a  processor 

module's  root 

process  at  the  end  of  the  simulation. 

Symbol  Map: 

NONE 

YES 

Attribute  failure  intrpts  properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

enumerated 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  failure 

interrupts 

are  generated  for  a  processor  module's  root  process 

upon  failure  of  nodes  or  links  in  the  network  model. 

Symbol  Map: 

NONE 

YES 

Attribute  intrpt  interval  properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle  double 

N/A 

Attribute  Description: 

Private 

N/A 

Units: 

sec. 

YES 

Comments: 

YES 

This  attribute  specifies  how  often  regu 

ar  interrupts 

are  scheduled  for  the  root  process  of  e 

i  processor  module. 

Symbol  Map: 

NONE 

YES 

Attribute  priority  properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

0 

N/A 

Default  Value: 

0 

YES 

Data  Type: 

integer 

N/A 

Attribute  Description: 

Private 

N/A 

Low  Range: 

-32767  inclusive 

YES 

High  Range: 

32767  inclusive 

YES 

Comments: 

YES 

This  attribute  is  used  to  determine  the  execution  order 

of  events  that  are  scheduled  to  occur  i 

it  the  same 

simulation  time. 

Symbol  Map: 

NONE 

YES 
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Attribute  recovery  intrpts  properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

enumerated 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  recovery  interrupts 

are  scheduled  for  the  processor 

module's  root  process 

upon  recovery  of  nodes  or  links 

in  the  network  model. 

Symbol  Map: 

NONE 

YES 

Attribute  super  priority  properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  is  used  to  determine  the  execution  order 

of  events  that  are  scheduled  to 

occur  at  the  same 

simulation  time. 

Symbol  Map: 

NONE 

YES 

Process  Model  Simulation  Attributes 

Attribute  class  A  CDV 

tolerance  properties 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 

variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  A  cells 

may  experience. 

Attribute  class  B  CDV 

tolerance  properties 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 

variance  that  two 
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consecutive  Quality  of 

Service  (QoS)  class  B  cells 

may  experience. 

Attribute  class  C  CDV  tolerance 

properties 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 

variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  C  cells 

may  experience. 

Attribute  class  D  CDV  tolerance 

properties 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 

variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  D  cells 

may  experience. 

Header  Block 


10 


15 


20 


#include  "/usr/local/mil3_dir/3  .0  . A_DL5 /model s/std/atm/ams_interf aces. h" 

#include  "  /usr/  local  /mi  13_dir/3  .0  .A_DL5 /model  s/std/atm/ams_aal_incer  faces  .  h" 

/*  Code  added  by  Clark  */ 

#include  "  /usr/work/benton/op_code/badd_interf  ace  .h" 

/*  end  code  added  by  Clark  *l 


I*  These  are  transition  conditions.  */ 
#define  SIGNAL 


#define  EST_CON 
#defme  RELJND 
#define  REL_CON 
#define  CALL  END 


((opintrpttype  ()  =  OPC_INTRPT_REMOTE)  &&       \ 
(op_intrpt_code  ()  =  AMSC_INTERFACE_SIGNAL)) 

(primitive  =  AMSC_AAL_ESTAB_Con) 

(primitive  =  AMSC_AAL_RELEASE_Ind) 

(primitive  =  AMSC_AAL_RELEASE_Con) 

((op_intrpt_type  ()  =  OPC_INTRPT_SELF)  &&  \ 

(op_intrpt_code  ()  ==  AMSC_TGEN_CALL_END)) 


/*,  These  are  the  amsjraf_gen  self  interrupt  codes.  *l 
#define    AMSC_TGEN_CALL_START      0 
#define  AMSC  TGEN  CALL  END     1 
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#define  AMSC_TGEN_DATA_GEN    2 

#define  BADD  CALL  RESCHEDULE     5 

25 

#define  BADD_CHECK_CHANNEL      6 

/*  The  ams  traf  gen  process  will  output  trace  information  if  this  conditional  is  true.  */ 
#define  LTRACE_ ACTIVE  (debug_mode  &&                                                                 \ 
(op  prg_odb_ltrace  active  ("ams")  II                               \ 

30 

op  prg  odb  Itrace  active  ("ams_traf")  II                       \ 
op  prg  odb  Itrace  active  ("ams_traf_gen"))) 

#defme  LTRACE_CONNECT_ACTIVE                      (opprgodbltraceactive  ( "connect ")) 

35 

/*  Code  added  for  badd  */ 

#define  LTR  ACE_STATIC_PCR_  ACTIVE                 (opprgodbltraceacti  ve  (  •  stat  ic_pcr  ■)) 

#define  LTRACE_CALL_GENERATOR_ ACTIVE    (op_prg_odb_ltrace_active  ( "cal  l_generator ")) 

40 

#defme  LTRACE_CALL_GEN_ACTIVE                   (op_prg_odb_ltrace_active  ("cal  l_gen")) 

#define  LTRACE_CALL_RESCHEDULER_ ACTIVE        (op_prg_odb_ltrace_active  ("cal  l_res chedu  1  e r 

')) 

#define LTRACE_CALL_COMPLETE_ ACTIVE       (op  prg  odb  Itrace  active("call_complete")) 

45 

/*  Procedure  declarations.  */ 

void  badd_call_gen_spurious_signal_handle  (); 

void  badd_call_gen_error  (); 

50 

55 

State  Variable  Block 


10 


15 


20 


int 

\iny_pro_id; 

int 

\dest_addr; 

int 

^packet_size; 

int 

\AAL_type; 

int 

Vjos_class; 

int 

V;hannel_assigned; 

int 

\debug_mode; 

int 

\lo_aal_stream_index 

double 

\int_arr_time; 

double 

\caJl_wait_ttme; 

double 

\call_duration; 

double 

\peak_cell_rate; 

double 

Navg_rate; 

double 

\channel_delay; 

char 

\pid_string[128]; 

Objid 

\my_id; 

Objid 

\aal_module_id; 

Objid 

Sparent_obj_id; 

Ici* 

\aal_handle_iciptr; 

Ici* 

Nchannel_iciptr; 
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Evhandle                        Niiext_packet_arrival; 

Evhandle                        \call_end_intrpt; 

Distribution*           \int_arrival_distptr. 

Distribution*           \calI_duration_distptr; 

25 

Prohandle                               \my_prohandle; 

Badd_Sch_Mod_Data*          Nmodule_data_ptr; 

AmsT_Traf_Contract*       Ntraf_con_ptr; 

AmsT_Neighbor_Data*         \nbr_data_ptr. 

30 

Temporary  Variable  Block 


10 


15 


20 


/*  Code  added  for  BADD  */ 


int 

primitive; 

int 

badd_dest_addr. 

double 

start. 

.time; 

double 

badd 

_packet_size; 

double 

event_tune; 

double 

end_sim_time; 

double 

cdv_tolerance; 

extern  int 

total_calls_generated 

extern  int 

total_calls_received; 

Ici* 

call_iciptr; 

Ici* 

upper. 

handle_iciptr, 

Ici* 

if_iciptr; 

Packet* 

pkptr. 

AmsT_Traf_Contract*    tmp_traf_con_ptr; 
/*  End  code  added  for  BADD  *l 


Function  Block 

void 

badd_call_gen_spurious_signaI_handle  () 

Ici*                          if_iciptr; 

5 

Ici*                           release_if_iciptr; 
int                           primitive; 
Ici*                          ll_handle_iciptr. 
Packet*                  pkptr. 

10 

/*  This  procedure  handles  spurious  interrupts. 

*/ 

1*  Only  three  Types  of  spurious  interrupts  can  be  accepted.  All 

*/ 

/*  others  must  result  in  an  op  sim  end  ().  These  three 

*/ 

1*  interrupts  are: 

*/ 

1*      1.  AnAALESTABInd. 

*/ 

15 

1*     2.  An  AAL  RELEASE  Con. 

*/ 

1*      3.  A  packet  arrival. 

*/ 

FIN  (ams_traf_gen_spurious_signal_handIe  ()); 

if  (SIGNAL) 
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20 


25 


30 


35 


40 


45 


50 


55 


60 


65 


70 


75 


/*  This  is  a  signal  from  the  AAL.  */ 

/*  Obtain  the  IC I  pointer.  *l 

if_iciptr  =  op_intrpt_ici  (); 

/*  Obtain  the  primitive  from  the  ICI.  */ 

op_ici_attr_get  (if_iciptr,  "primit  ive ",  &primitive); 

/*  Obtain  the  'lower  layer  handle'  from  the  ICI.  */ 

op_ici_attr_get  (if_iciptr,  "lower   layer  handle",  &ll_handle_iciptr); 

/*  Switch  on  the  'primitive' .  */ 

switch  (primitive) 
{ 

case  AMSC_AAL_ESTAB_Ind: 
{ 
/*  This  is  an  'establish  indication'  from  the  AAL.  *t 

if(L"reACE_ACTIVE) 

{ 

op_prg_odb_print_major  (pid_string,  "Received  spurious  AAL  ESTABLISH  Request  signal 
"Call  not  accepted.  ",  "Sending  AAL  RELEASE  Request  signal  .",  OPC_NIL); 


} 


/*  Set  the  'upper  layer  handle'  in  the  interface 

I*  ICI  for  the  'establish  indication  signal,  since 

I*  the  lower  layer  expects  it  to  be  filled  in.  The 

I*  ICI  is  not  destroyed,  since  this  is  a  forced 

I*  interrupt  and  the  lower  layer  process  expects 

I*  to  obtain  the  handle  from  the  ICI  when  the 

I*  control  returns. 

op_ici_attr_set  (if _iciptr,  "upper   layer  handle",  OPC_NIL); 


*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 


*/ 


/*  Simply  send  an  AALRELEASEReq  to  request  that 
I*  the  connection  be  released.  *l 

release_if_iciptr  =  opicicreate  (AMSCJNTERFACEJCI); 
op_ici_attr_set(release_if_iciptr,  "primitive",  AMSC_AAL_RELEASE_Req); 
op_ici_attr_set  (release_if_iciptr,  "lower   layer  handle",  ll_handle_iciptr); 
op_ici_install  (release_if_iciptr); 

/*  Send  a  remote  interrupt  which  will  carry  the  ICI  to  the  AAL  module.  */ 
op_intrpt_schedule_remote  (op_sim_time  (),  AMSC_INTERFACE_SIGNAL,  aal_module_id); 

break; 


case  AMSC_AAL_RELEASE_Con: 

( 

/*  This  is  a  'release  confirm  from  the  AAL. 

if(LTRACE_ACTIVE) 


*/ 


op_prg_odb_print_major  (pid_string,  "Received   spurious   AAL   RELEASE  Confirm   signal.", 
"This    is    in   response   to   AAL   RELEASE   Request    terminating   spurious    connection. 


/*  This  is  a  response  to  our  earlier  'release 
/*  request'  which  was  a  response  to  the 
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/*  spurious  '  estab  indication  . 

*/ 

80 

1*  Do  nothing  other  than  destroy  the  ICI. 
op_ici_destroy  (ifjciptr); 

break; 

) 

*/ 

85 

default 

I 

/*  This  is  some  other  completely  unexpected 

*/ 

1*  signal.  Issue  error  message  and  terminate 

*/ 

90 

!*  simulation. 

} 
} 
} 
else  if  (opintrpttype  ()  =  OPC_INTRPT_STRM) 

i 

*/ 

95 

l 

/*  This  is  a  spurious  packet  arrival.  The  ams  traf  gen                                 *l 

1*  just  destroys  this  packet.                                                                             */ 

if(LTRACE  ACTIVE) 

100 

( 

op_prg_odb_print_major  (pid_string,  "Received  spurious  DATA 

packet .  ", 

"Destroying  the  packet .",  OPC_NIL); 
} 

105 

/*  Get  the  packet  fromt  the  stream  and  destroy  it.                                          *l 
pkptr  =  op_pk_get  (op_intrpt_strm  ()); 
op  pk  destroy  (pkptr); 
} 
else 

110 

{ 

/*  This  is  some  other  completely  unexpected                                          */ 
/*  interrupt.  Issue  error  message  and  terminate                                    */ 
/*  simulation.                                                                                           *l 

115 

) 

FOUT; 
} 

120 

void 

badd_call_gen_error  (msgO,  msgl,  msg2) 

char*               msgO; 

char*               msgl; 

char*               msg2; 

125 

{ 

/**  Print  an  error  message  and  exit  the  simulation.  **/ 

FIN  (badd_call_gen_error  (msgO,  msgl,  msg2)); 

op  sim  end("Error   in  badd_call_generator  process:". 

130 

msgO,  msgl,  msg2); 
FOUT; 
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Diagnostic  Block 


/*  Display  connection  information,  if  requested.  *l 
if  (LTRACE_CONNECT_ACTIVE) 

{ 

/*  Print  information.  *l 

ams_neighbor_data_print  (nbr_data_ptr,  ams_neighbor_desc_print_noop); 


forced  state    INIT 

attribute 

value 

tvoe 

default  value 

name 

enter  execs 
exit  execs 
status 

INIT 

(See  below.) 

(empty) 

forced 

string 
textlist 
textlist 
toggle 

St 

(empty) 
unforced 

enter  execs    INIT 


10 


15 


20 


25 


30 


35 


/*  New  process  created  for  BADD  ATM  Simulation.  *l 

I*  This  process  generates  the  call  data  when  the  call  is  scheduled  */ 
/*  for  a  channel.  */ 

/*  Determine  if  the  simulation  is  in  debug  mode,  traces  are  only    *l 
I*  enabled  in  the  debug  mode .  *l 

debug_mode  =  op_sim_debug(); 

/*  Determine  the  prohandle  and  process  jd  for  this  instances  of  a  *l 
/*  badd_call_generalor.  */ 

my_prohandle  =  op_pro_self(); 
my_pro_id  =  op_pro_id(my_prohandle); 

if  (my_pro_id  ==  OPC_PRO_ID_INVALID) 

badd_call_gen_error( ■  Unable  to  get   own   process    id",  OPC_NIL,  OPC_NIL); 

parent_obj_id  =  op_pro_mod_objid(my_prohandle); 

/*  Initialize  the  process  ID  display  string  */ 

sprintf(pid_string,  "badd_call_gen   PID   (%d)  ",  my_pro_id); 

/*  Access  the  module  memory  data  structure  */ 

module_data_ptr  =  (Badd_Sch_Mod_Data*)op_pro_modmem_access(); 
if  (module_data_ptr  =  OPC_NIL) 

badd_call_gen_error( " Unable  to  get   module  memory- ",  OPC_NIL,  OPC_NIL); 

nbr_data_ptr  =  module_data_ptr->md_neighbor_data_ptr, 
channel_delay  =  moduIe_data_ptr->md_channel_deIay; 

/*  Access  the  argument  memory  and  get  the  call  descriptor  *l 

I*  information.  */ 

call_iciptr  =  (Ici*)op_pro_argmem_access(); 

if  (LTRACE_CALL_GENERATOR_ACTrVE) 

{ 
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printf("In   badd_call_gen  .  init :   my_prohandle   =   %x.  \n",  my_prohandle); 
printf("In   badd_call_gen.  init :    call_iciptr   =   %x.  \n",  caJl_iciptr); 
printf("In  badd_call_gen.  init ,-    pro_id   =   %d .  \n",  my_pro_id); 


if  (calljciptr  =  OPC_NIL) 

badd_call_gen_error( "  In  badd_cal  l_gen.  init : 


unable    to   get   cal  l_icipt  r .  ",  OPC_NIL,  OPC_NIL); 


if  ((op_ici_attr_get  (call_iciptr, 
(op_ici_attr_j>et  (call_iciptr, 
(op_ici_attr_get  (call_iciptr, 
(op_ici_attr_get  (cal)_iciptr, 
(op_ici_attr_get  (call_iciptr, 
(op_ici_attr_get  (call_iciptr, 
(op_ici_attr_get  (call_iciptr, 
(op_ici_attr^get  (call_iciptr, 
(op_ici_attr_get  (call_iciptr, 
badd_call_gen_error("In  sta 


•  interarrival    time",  &int_arr_time)  =  OPC_COMPCODE_FATLURE)  II 

packet  size-.  &packet_size)  =  OPC_COMPCODE_FAILURE)        II 

call   wait   t i me ■ ,  &call_wait_time)  =  OPC_COMPCODE_FAILURE)  II 

call    duration',  &call_duration)=OPC_COMPCODE_FAILURE)     II 

dest   addr\&dest_addr)  =  OPC_COMPCODE_FAILURE)  II 

QoS  class\&qos_class)  =  OPC_COMPCODE_FAILURE)  II 

AAL  type-,&AAL_type)==OPC_COMPCODE_FAEJURE)  II 

channel   assigned",  &channel_assigned)  =  OPC_COMPCODE_FATLURE) 

peak  cell   rate",  &peak_cell_rate)  =  OPC_COMPCODE_FATLURE)) 

rt   call,    unable   to   get   values    from  cal  l_iciptr ",  OPC_NIL,  OPC_NEL); 


if  (LTRACE_CALL_GENfER  ATOR_ACTrVE) 

( 

printf("In  badd_call_gen.  init ;    packet_size   =   %d  .  \n",  packet_size); 

printf("In  badd_call_gen.  init 

printf("In  badd_call_gen.  init 

printf("In  badd_call_gen .  init 

printf("In  badd_call_gen.  init 

printf("In  badd_call_gen.  init 

printf("In  badd_call_gen.  init 

printf("In  badd_call_gen.  init 


dest_addr   =   %d.  \n",  dest_addr); 
AAL_type  =  %d .  \n ",  AAL_type); 
qos_class  =  %d.  \n°,  qos_dass); 
int_arr_time   =  %f  .  \n",  int_arr_tinie); 
call_wait_time  =  %f .  \n",  call_wait_time); 
call_duration  =  %f .  \n",  calI_duration); 
channel   assigned  =   %d.  \n",  channel_assigned); 


/*  Release  the  memory  for  this  call  descriptor  *l 
op_ici_destroy(call_iciptr); 

/*  Load  in  the  packet  interarrival,  call  wait  and  call  duration  */ 

/*  distributions.  *l 

int_arrivaJ_distptr   =  op_dist_load  ( "constant " ,  int_air_time,  0.0); 
call_duration_distptr  =  op_dist_load  ("constant",  call_duration,  0.0); 

/*  Code  added  for  BADD  *l 

badd_packet_size  =  packet_size; 

peak_ceil_rate  =  (1.0  /  int_arr_time)  *  (badd_packet_size  /  AMSC_ATM_CELL_DATA_SIZE); 

if  (LTRACE_CALL_GENERATOR_  ACTIVE) 

( 
printfCIn   badd_call_gen,    Init;    Peak_Cell_Rate   =   %f .  \n",  peak_cell_rate); 
pnntfl  "\t  Int_Arr_Time   =    %f,    \tPacket_Size   =   %d  .  \n",  int_arr_time,  packet_size); 


/*  Code  for  getting  the  simulation  duration  *l 
op_ima_sim_attr_get(OPC_IMA_DOUBLE,  "duration",  &end_sim_tin)e); 

if  (LTRACE_CALL_GENERATOR_ACTrVE) 

( 

pnntfl  "Ir.   badd_call_gen,    Init;    end_sim_time   =   %f .  \n",  end_sim_time); 
} 
I*  End  Code  added  for  BADD  *l 

I*  Use  the  default  Cell  Delay  Variation  (CDV)  tolerance  for  the  *! 
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95 

/*  specific  QoS  class. 

cdv_tolerance  =  ams_CDV_tolerance_default_obtain  (qos_class); 

*/ 

/*  Create  a  traffic  contract  for  calls  originating  from  this  src. 

*/ 

1*  There  is  no  return  traffic,  but  allocate  a  bit  (.1  *  PCR)  of 

*/ 

100 

1*  bandwidth  anyway. 

traf_con_ptr  =  ams_traffic_contract_create  (peak_cell_rale, 
peak_cell_rate  *  0.1,  cdv_tolerance,  cdv_tolerance); 

/*  Initialize  the  AAL  module  object  ID  and  aal  stream  index.    *l 

*/ 

105 

aal_module_id  =  module_dala._ptr->md_aal_module_id; 
to_aal_stream_index  =  module_data_ptr->md_to_aa]_stream_index; 

if  (LTRACE.C  ALL_GENERATOR_  ACTIVE) 

printf("In  badd_call_gen;    aal_rnodule_id   =   %d.  \n",  aal_module_id); 

110 

/*  Generate  P1D  display  string. 

*/ 

sprintf  (pid_string,  "badd_call_gen   PID   (%d)  ",  op_pro_id  (op_pro_self  ())); 
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/*  Start  a  call  by  issuing  a  call  open  request  to  the  ATM 

*/ 

1*  adaptation  layer. 

*/ 

if(LTRACE_ACTIVE) 

( 

5 

i 

op_prg_odb_print_major  (pid_string,  "  Initiating   call    SETUP.", 

"Sending  AAL  ESTABLISH   Request   signal. ",OPC 
} 

.NIL); 

10 

/*  Make  a  copy  of  the  traffic  contract,  since  the  lower  layers 

*/ 

1*  are  responsible  for  destroy  the  data  structure. 

*/ 

tmp_traf_con_ptr  =  ams_traffic_contract_copy  (traf_con_ptr); 

upper_handle_iciptr  =  op_ici_create("badd_cali_gen_handle"); 
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op_ici_attr_set  (upper_handle_iciptr,  . ca  ^  i_gen_prohand  1  e " ,  &my_prohandle); 


/*  Create  and  set  the  fields  in  the  interface  JCI. 
ifjciptr  =  op_ici_create  (BADD_CALL_GEN_EF_ICI); 


*/ 


op_ici_install  (if_ic 
op_ici_attr_set  (if_: 
op_ici_attr_set  (if_i 
op_ici_attr_set  (if_i 
op_ici_attr_set  (if. 
op_ici_attr_set  (if_i 
op_ici_attr_set  (if. 
op_ici_attr_set  (if_ 
op_ici_attr_set  (if_ 
op_ici_attr_set  (if 


ptr); 

ciptr,  -primitive",  AMSC_AAL_ESTAB_Req); 

ciptr,  "address",  dest_addr); 

ciptr,  "called  party  SAP",  AMSC_AAL_SAP_ANY); 

ciptr,  "QoS  class",  qos_class); 

ciptr,  "upper   layer  handle",  upper_handle_iciptr); 

ciptr,  "AAL  type",  AAL_type); 

ciptr,  "traffic   contract ",  tmp_traf_con_ptr); 

ciptr,  "badd_cal  l_gen_pro_id",  my_pro_id); 

ciptr,  "badd_cal  l_gen_channel_id",  channel_assigned); 


/*  Code  added  for  BADD  *l 

if  (LTRACE_CALL_GENER  ATOR_ACriVE) 

{ 

printf("In   badd_call_generator,    start;    starting  call    to  dest   %d .  \n",  dest_addr); 

printf("In  badd_call_generator,    start;    aal_module_id   =   %d .  \n",  aal_module_id); 
}  /*  End  ij -(LTRACE  CALL  GENERATOR  ACTIVE)  */ 


/*  End  of  code  added  for  BADD  */ 

/*  Send  a  remote  interrupt  which  will  carry  the  ICI  to  the  AAL 
I*  module. 


opjDtrpt_scbedule_remote  (op_sim_time  (),  AMSC_INTERFACE_SIGNAL,  aal_module_id); 
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if  (LTRACE_CALL_GENERATOR_ACTrVE) 
{ 
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printf("In   call_gen.EstCon. enter  execs  .  \n",  OPC_NIL,  OPC_NIL); 


exit  execs    EstCon 
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/*  This  slate  expects  three  possible  interrupts:  */ 

/*  1.  Establish  Confirm  signal.  */ 

/*  2.  Release  Indication  signal.  *l 

I*  3.  Spurious  signal.  *l 

if  (LTRACE_CALL_GENERATOR_  ACTIVE) 

1 

printf("In  badd_call_gen.  EstCon:    call_gen   restarted.  \n"); 
} 

/*  Determine  what  signal  arrived. 
I*  Obtain  the  interface  ICI  pointer. 
if_iciptr  =  op_intrpt_ici  (); 

/*  Obtain  the  primitive  value. 

op_ici_attr_get  (if_iciptr,  "primitive",  &primitive); 

/*  Switch  off  the  primitive  value. 
switch  (primitive) 
{ 

case  AMSC_AAL_ESTAB_Con: 
{ 

/*  The  signal  is  an  AAL  ESTABLISH  Confirm  signal.  *l 

I*  The  connection  has  been  established.  */ 

if(LTRACE_ACTIVE) 

op_prg_odb_print_major  (pid_string,  "Received  AAL  ESTABLISH  Confirm  signal. 
"Connection  established.  ",  OPC_NIL); 

/*  Obtain  the  lower  layer  handle.  *l 

op_ici_attr_get  (if_iciptr,  "lower   layer  handle",  &aal_handle_iciptr); 

/*  Destroy  the  ICI.  *l 

op_ici_destroy  (if_iciptr); 


*/ 
*/ 


*/ 


*/ 


*/ 


/*  Schedule  the  call  end  event. 

call_end_intrpt  =  op_intrpt_schedule_self  (op_sim_time  ()  + 

opdistoutcome  (call_duration_distptr),  AMSC_TGEN_CALL_END); 

/*  Schedule  the  next  arrival.  *l 

next_packet_arrival  =  op_intrpt_sctaedule_self  (op_sim_time  ()  + 

op_dist_outcome  (int_arrival_distptr),  AMSC_TGEN_DATA_GEN); 

if  (LTRACE_CALL_GENERATOR_ACTrVE) 
( 

start_time  =  op_sim_time  ()  +  op_dist_outcome  (int_arrival_distptr); 

printf("In   badd_call_gen.  EstCon:    start    time    =   %f  .  \n",  start_time); 


break; 

I 

case  AMSC_AAL_RELEASE_Ind: 
I 
/*  The  signal  is  an  AAL  RELEASE  Indication  signal.  */ 
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/*  The  connection  has  been  terminated.  */ 

if  (LTRACE_  ACTIVE) 

op_prg_odb_print_major(pid_string,  "Received  AAL  RELEASE   Indication   signal 
"Connection   terminated .",  OPC_NIL); 


/*  Destroy  the  Id. 

op_ici_destroy  (if_iciptr); 
break; 


*/ 


default: 

{ 

/*  This  is  a  spurious  signal.  */ 

printf("In   badd_call_gen  .  EstCon   state;    inside   switch   statement  -  \n"); 
badd_call_gen_spurious_signal_handle  (); 
break; 
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if  (LTRACE_C  ALL_GENER  ATOR_ACTIVE) 

( 
printf("In   call_gen,    received   signal    to   start   sending   data.  \n",  OPC_NIL,  OPC_NIL); 


exit  execs    data  aen 

/*  This  state  expects  four  possible  interrupts: 

*/ 

1*  l.An  AAL  RELEASE  Indication  signal. 

*/ 

1*  2.  A  Spurious  signal. 

*/ 

1*  3.  A  call  end  interrupt. 

*/ 

5 

1*  4.  A  generate  data  interrupt. 

if  (LTRACE_C  ALL_GENER  ATOR_ACTIVE) 

{ 

printf("In   badd_call_gen.  data   gen. exit   execs. \n"); 

*/ 

10 

} 

/*  Determine  if  this  is  an  AAL  signal. 

*/ 

15 

if  (SIGNAL) 

I 

/*  Obtain  the  interface  JCl  and  enclosed  primitive. 

*/ 

if_iciptr  =  op_intrpt_ici  (); 

op_ici_attr_get  (ifjciptr,  "  pr  imi  t  i  ve " ,  &primitive); 

20 

/*  If  the  primitive  is  'release  indication' , 

*/ 

/*  cancel  the  call  end  and  data  gen  intrpts; 

*/ 

1*  otherwise,  the  primitive  indicates  a 

*/ 

1*  spurious  signal. 

*/ 

25 

if  (primitive  =  AMSC_AAL_RELEASE_Ind) 

/ 

1*  This  is  a  'release  indication  signal. 

*/ 

if(LTRACE_ACTIVE) 

op_prg_odb_print_major  (pid_string,  "Received  AAL  RELEASE 

Indication 

signal  .  ", 

30 

"Connection   terminated. ",  OPC_NIL); 

/*  Cancel  the  'call  end'  and  'generate  data'  events. 

*/ 

op_ev_cancel  (next_packet_arrival); 

op_ev_cancel  (call_end_intrpt); 

35 

/*  Destroy  the  ICI. 

*/ 

op_ici_destroy  (ifjciptr); 

1 

) 
else 

40 

{ 

/*  This  is  a  spurious  signal. 

*/ 

ams_traf_gen_spurious_signal_handle  (); 

} 

} 
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/*  Determine  whether  this  interrupt  is  a  self  interrupt  *l 

/*  that  indicates  the  end-of-call.  *l 

elseif(CALL_END) 

{ 

/*  This  is  a  self  interrupt  that  indicates  the  end-of-call.  */ 

if(LTRACE_ACTIVE) 

{ 

op_prg_odb_print_major  (pid_string,  "  Initiating   call   END.", 

"Sending  AAL   RELEASE   Request    signal  .",  OPC_NIL); 


/*  Cancel  the  current  packet  arrival  interrupt.  */ 

op_ev_cancel  (next_packet_arrival); 

I*  Notify  the  AAL  that  the  call  is  complete.  *l 

if_iciptr  =  op_ici_create  (BADD_CALL_GEN_IF_ICI); 
op_ici_attr_set  (if_iciptr,  "primitive",  AMSC_AAL_RELEASE_Req); 
op_ici_attr_set(if_iciptr,  "lower   layer  handle",  aal_handle_iciptr); 
op_ici_attr_set  (if_iciptr,  "badd_call_gen_channel_id",  channel_assigned); 
op_ici_install  (if_iciptr); 

if  (LTRACE_CALL_GENER  ATOR_ACTIVE) 

{ 
printf("In   call_gen.data_gen:    call   completed   for  channel    %d.  \n",  channel_assigned); 


/*  Send  a  remote  interrupt  that  will  carry  the  ICI  to  the  AAL  */ 

/*  module.  *l 

opintrptscheduleremote  (opsimtime  (),  AMSC_INTERFACE_SIGNAL,  aal_module_id); 


else  if  (op_intrpt_type  ()  =  OPC_INTRPT_STRM) 

{ 

/*  This  is  a  spurious  signal. 

badd_call_gen_spurious_signal_hancile  (); 


*/ 


else 


/*  This  is  a  generate  data'  event.  */ 

if(LTRACE_ACTIVE) 

op_prg_odb_print_major  (pid_string,  "Sending   DATA .  " ,  OPC_NIL); 

/*  Install  the  AAL  handle  ICI.  *l 

op_ici_install  (aal_handle_iciptr); 

/*  Create  a  data  packet  and  send  it  to  the  AAL.  *l 

pkptr  =  op_pk_create  (packet_size); 

if  (LTRACE.C  ALL_GENERATOR_ACTIVE) 


f 


printf("In   badd_call_gen.data   gen,-   pk  created  with   addr  %d.  \n",  dest_addr); 
printf("In  badd_call_gen.data   gen,-    pk   created  with   size   =   %d .  \n",  packet_size); 
printf("In  badd_call_gen.data   gen;   pk   send   to  strm    index   %d.    \n",  to_aal_stream_index); 


} 


op_pk_send  (pkptr,  to_aal_stream_index): 

/*  Schedule  the  next  arrival. 
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105 


next_packet_arrival  =  op_intrpt_schedule_self  (op_sim_time  ()  + 

op_dist_outcome  (int_arriva]_distptr),  AMSC_TGEN_DATA_GEN); 


transition    data 

qen 

->  RelCon 

attribute 

value 

tvpe 

default  value 

name 

tr  14 

string 

tr 

condition 

CALL  END 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

spline 

toggle 

spline 

transition    data 

qen 

->  reschedule 

attribute 

value 

tvpe 

default  value 

name 

tr  101 

string 

tr 

condition 

REL  IND 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

spline 

toggle 

spline 

transition    data 

qen-> 

data 

qen 

attribute 

value 

tvpe 

default  value 

name 

tr  111 

string 

tr 

condition 

default 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

spline 

toggle 

spline 

unforced  state    RelCon 

attribute 

value 

tvpe 

default  value 

name 

enter  execs 
exit  execs 
status 

RelCon 
(See  below.) 
(See  below.) 
unforced 

string 
textlist 
textlist 
toggle 

St 

unforced 

enter  execs    RelCon 


if  (LTRACE_CALL_GENERATOR_  ACTIVE) 
( 
printf("In   call_gen. RelCon. enter  execs  .  \n",  OPC_NIL,  OPC_NIL); 
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exit  execs    RelCon 

/*  This  state  expects  two  possible  interupts: 
1*  1.  An  AAL  RELEASE  Confirm  signal. 
I*2.A  spurious  signal. 

*/ 
*/ 
*/ 

5 

1*  Determine  what  signal  arrived. 

1*  Obtain  the  interface  1C1  and  enclosed  primitive. 

if_iciptr  =  op_intrpt_ici  (); 

*/ 
*/ 

10 

op_ici_attr_get  (if_iciptr,  "primitive",  &primitive); 

15 

/*  If  this  is  a  'AAL  RELEASE  Confirm'  signal,  do  nothing; 

1*  otherwise,  this  is  a  spurious  signal. 

if  (primitive  =  AMSC  AAL  RELEASE  Con) 

{ 

*/ 
*/ 

20 

l*printf("ln  call-generator  RelCon:  Peak  Cell  Rate  =  %f.\n",  peak  cell 
1*  This  is  a  'AAL  RELEASE  Confirm'  signal. 
if  (LTRACE  CALL  GENERATOR_ACTrVE) 
( 

rate);  *l 

op_prg_odb_print_major  (pid_string,  "Received  RELEASE  Conf 
"Call    END   complete .",  "Connect ion   terminated." 

irm   signal  .  ", 
,  OPC_NIL); 

25 

/*  Destroy  the  ICI. 

op  ici  destroy  (if_iciptr); 

}  ' 
} 
else 

*/ 

30 

I 

/*  This  is  a  spurious  signal. 

badd_calI_gen_spwious_signal_handIe  (); 
) 

*/ 

transition     RelCon 

->  call  done 

attribute 

value 

tvpe 

default  value 

name 

tr  103 

string 

tr 

condition 

REL  CON 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

spline 

toggle 

spline 

transition     RelCon 

->  RelCon 

attribute 

value 

tvpe 

default  value 

name 

tr  113 

string 

tr 

condition 

default 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

spline 

toggle 

spline 
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unforced  state    reschedule 

attribute 

value 

tvoe 

default  value 

name 

enter  execs 
exit  execs 
status 

reschedule 
(See  below.) 
(empty) 
unforced 

string 
textlist 
textlist 
toggle 

st 

(empty) 
unforced 

enter  execs    reschedule 


10 


15 


20 


25 


30 


35 


40 


if  (LTRACE.C  ALL_GENERATOR_ACTIVE) 

{ 
printf("In  call_gen.  reschedule. enter  execs  .  \n",  OPC_NIL,  OPC_NIL); 


if_iciptr  =  op_ici_create  ("badd_call_req_if_ici  "); 
op_ici_install(if_iciptr); 

op_ici_attr_set (if_iciptr,  "interarrival  time",  int_arr_time); 
op_ici_attr_set  (if_iciptr,  "packet   size",  packet_size); 
op_ici_attr_set (if_iciptr,  "call    wait   t ime " ,  call_wait_time); 
op_ici_attr_set  (if_iciptr,  "call   duration",  call_duration); 
op_ici_attr_set  (if_iciptr,  "dest    addr",  dest_addr); 
op_ici_attr_set  (if_iciptr,  "QoS  class",  qos_class); 
op_ici_attr_set  (if_iciptr,  "AAL  type",  AAL_type); 
op_ici_attr_set  (if_iciptr,  "peak  cell   rate",  peak_cell_rate); 
op_ici_attr_set  (if_iciptr,  "channel   ass  igned ",  channel_assigned); 

op_intrpt_schedule_remote(op_sim_time()  +  channel_delay,  BADD_CALL_RESCHEDULE,  parent_obj_id); 

/*  Need  to  send  inirpi  to  run  a  reschedule  event  */ 
if  (LTRACE_CALL_RESCHEDULER_  ACTIVE) 
{ 
op_prg_odb_print_major(pid_string,  ■  Ca  1 1   Terminated,    Call    Rescheduled.", 
"Destroying  call_gen   process  .",  OPC_NIL); 


/*  Send  intrpt  to  check  for  next  call  on  this  channel  */ 
channel_iciptr  =  op_ici_create("badd_channel_ici "); 
op_ici_install(channel_iciptr); 

op_ici_attr_set  (channel_iciptr,  "channel   number",  channel_assigned); 
if  (LTRACE.C  ALL_RESCHEDULER_  ACTIVE) 
{ 
printf("ln  call_gen.call_done,    channel   released   =   %d.  \n",  channel_assigned); 

} 

op_intrpt_schedule_remote(op_sinj_time(),  BADD_CHECK_CHANNEL,  parent_obj_id); 

/*  This  process  destroys  itself  since  the  call  is  released  *l 

if  (op_pro_destroy(my_prohandle)  =  OPC_COMPCODE_FATLURE) 

{ 
badd_call_gen_error("Onable   to  terminate  call_gen   process  .",  OPC_NEL,  OPC_NIL); 
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:- 

unforced  state    call  done 

attribute 

value 

tvpe 

default  value 

name 

enter  execs 
exit  execs 
status 

call  done 
(See  below.) 
(empty) 
unforced 

string 
textlist 
textlist 
toggle 

St 

(empty) 
unforced 

enter  execs    call  done 


10 


15 


20 


if  (LTRACE_CALL_GENERATOR_  ACTIVE) 
{ 
op_prg_odb_print_major(pid_string,  "Call  Successfully  Completed.", 
"Destroying   call_gen   process  .",  OPC_NIL); 


/*  Send  imrpl  to  schedule  next  call  */ 
channel_iciptr  =  op_ici_create("badd_channel_ici "); 
op_ici_install(channel_iciptr); 

op_ici_attr_set  (channel_iciptr,  "channel   number",  channel_assigned); 
if  (LTRACE_CALL_COMPLETE_  ACTIVE) 
{ 
printf("In   cal  l_gen.call_done,    channel    completed   =    %d .  \n",  channel_assigned); 

) 

op_intrpt_schedule_remote(op_sini_time(),  BADD_CHECK_CHANNEL,  parent_obj_id); 

/*  This  process  destroys  itself  since  the  call  is  completed  */ 

if  (op_pro_destroy(my_prohandle)  =  OPC_COMPCODE_FAILURE) 

( 
badd_call_gen_error(" Unable  to  terminate  call_gen   process  .",  OPC_NIL,  OPC_NIL); 
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External  File  Set 


attribute 


value 


type 


default  value 


external  file  set 


badd  functions 


typed  file 


Process  Model  Comments 


General  Process  Description: 


The  badd_call_scheduler  schedules  and  manages  all  static  channel 
assignments  for  the  BADD  network.  This  model  schedules  calls  by  assigning 
new  calls  to  the  channel  with  the  least  number  of  calls  current  scheduled. 

ICI  Interfaces: 


badd_cal  l_req_if_ici 
badd_call_gen_if_ici 

Packet  Formats: 

None. 

Statistic  Interfaces: 

None 

Process  Registry: 

Published  Attributes  and  Expected  Attributes:  None 

Restrictions: 

None 


Process  Model  Attributes 

Attribute  dest  addr  properties 

Property 

Value 

Default  Value: 

NONE 

Data  Type: 

integer 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Specifies  the  destination  of 

the  call. 

Symbol  Map: 

Symbol                                     Value 

NONE                                       -1 

Allow  other  values: 

YES 

Attribute  scheduler  delay  properties 

Property 

Value 

Default  Value: 

0.0 
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Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Units: 

seconds 

Comments: 

The  maximum  time  in  seconds 

between  scheduler  events. 

Attribute  transmission  delay  properties 

Property 

Value 

Default  Value: 

0.25 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Units: 

seconds 

Attribute  channel  delay  properties 

Property 

Value 

Default  Value: 

7.681  E-05 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Units: 

seconds 

Comments: 

The  delay  between  calls  on 

the  same  channel. 

Attribute  calls  pending  properties 

Property 

Value 

Default  Value: 

0 

Data  Type: 

integer 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

The  maximum  number  of  calls 

to  store  in  the 

calls_pending  list  before 

running  a  schedule  process. 

Process  Model  Interface  Attributes 

Attribute  begsim  intrpt  properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

enabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies 

whether  a 

'beg 

n  simulation 

interrupt' 

is  generated 

for 

a  proce 

ssor 

module's 

root 

process 

at  the  start  of  the 

simulation. 
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Symbol  Map: 

NONE 

YES 

Attribute  endsim  intrpt  properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

enabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  an  'end  simulation 

interrupt'  is  generated  for  a  processor 

module's  root 

process  at  the  end  of  the  simulation. 

Symbol  Map: 

NONE 

YES 

Attribute  failure  intrpts  properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

enumerated 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  failure  interrupts 

are  generated  for  a  processor  module' 

s  root  process 

upon  failure  of  nodes  or  links  in  the  network  model. 

Symbol  Map: 

NONE 

YES 

Attribute  intrpt  interval  properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle  double 

N/A 

Attribute  Description: 

Private 

N/A 

Units: 

sec. 

YES 

Comments: 

YES 

This  attribute  specifies  how  often  regular  interrupts 

are  scheduled  for  the  root  process  of  a 

processor  module. 

Symbol  Map: 

NONE 

YES 

Attribute  priority  properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

0 

N/A 

Default  Value: 

0 

YES 

Data  Type: 

integer 

N/A 

Attribute  Description: 

Private 

N/A 

Low  Range: 

-32767  inclusive 

YES 

High  Range: 

32767  inclusive 

YES 
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Comments: 

YES 

This  attribute  is 

used  to  determine  the  execution  order 

of  events  that  are  scheduled  to 

occur  at  the  same 

simulation  time. 

Symbol  Map: 

NONE 

YES 

Attribute  recovery  intrpts 

properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

enumerated 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether 

recovery  interrupts 

are  scheduled  for  the  processoi 

module's  root  process 

upon  recovery  of  nodes  or  links  in  the  network  model. 

Symbol  Map: 

NONE 

YES 

Attribute  super  priority  properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  is 

used  to  determine  the  execution  order 

of  events  that  are  scheduled  to 

occur  at  the  same 

simulation  time. 

Symbol  Map: 

NONE 

YES 

Process  Model  Simulation  Attributes 

Attribute  class  A  CDV 

_tolerance  properties 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 

variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  A  cells 

may  experience. 

Attribute  class  B  CDV 

tolerance  properties 

Property 

Value 

Default  Value: 

0.0 
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Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 

variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  B  cells 

may  experience. 

Attribute  class  C  CDV  tolerance 

properties 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 

variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  C  cells 

may  experience. 

Attribute  class  D  CDV  tolerance 

properties 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 

variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  D  cells 

may  experience. 

Header  Block 


10 


15 


#include  "/usr/local/mil3_dir/3  .0  .A_DL5 /model s/std/atm/ams_interf  aces  .h" 
#include  ■/usr/local/mil3_dir/3  . 0. A_DL5 /model s/std /at m/ams_aal_inter faces  .  h" 
frinclude  "  / us r /wo rk / bent on /op_code/badd_int erf ace  .  h" 

/*  These  are  transition  conditions.  *l 

#define  SIGNAL      ((opjntrptjype  ()  =  OPCJNTRPT_REMOTE)  &&  \ 
(op_intrpt_code  ()  =  AMSC_INTERFACE_SIGNAL)) 

#define  CALL_REQ_SIGNAL     ((opjntrptjype  ()  =  OPC_INTRPT_REMOTE)  &&  \ 
(op_intrpt_code  ()  =  BADD_REQUEST_SIGNAL)) 


#defme  AAL_CALL_SETUP 


#define  SAAL_SIGNAL 


((SIGNAL)  &&  \ 

((primitive  ==  AMSC_AAL_ESTAB_Req)  II       \ 
(primitive  =  AMSC_AA_ESTAB_Ind))) 

((opjntrptjype  ()  =  OPC_INTRPT_REMOTE)  &&  \ 
(op  intrpt  code  ()  ==  AMSC_SAAL_SIGNAL)) 
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20 


25 


30 


35 


40 


45 


50 


55 


60 


65 


70 


75 


#define  AAL_DATA 
#derme  EST_CON 
#define  REL_IND 
#defme  REL_CON 
#defme  CALL.START 

#defme  CALL_END 

#define  SCHEDULER 

#define  RESCHEDULE 


(opjntrpttype  ()  ==  OPC_INTRPT_STRM) 
(SIGNAL  &&  (primitive  ==  AMSC_AAL_ESTAB_Con)) 
(SIGNAL  &&  (primitive  =  AMSC_AAL_RELEASE_Ind)) 
(SIGNAL  &&  (primitive  =  AMSC_AAL_RELEASE_Con)) 


((op_intrpt_type  ()  =  OPC_INTRPT_SELF)  &&  \ 

(opintrptcode  ()  =  BADD_CALL_SCH_START)) 

((op_intrpt_type  ()  =  OPC_INTRPT_SELF)  &&  \ 

(opjntrpfcode  ()  =  AMSC_TGEN_CALL_END)) 

((op_intrpt_type  ()  =  OPC_INTRPT_SELF)  &&      \ 
(op_intrpt_code  ()  =  BADD_CALL_SCHEDULER)) 

((opintrpttype  ()  =  OPC_INTRPT_REMOTE)  &&    \ 
(op_intrpt_code  ()  =  BADD_CALL_RESCHEDULE)) 

#define  CHECK_CHANNEL_SIGNAL  ((opjntrpttype  ()  =  OPC_INTRPT_REMOTE)  &&    \ 

(op_intrpt_code  ()  =  BADD_CHECK_CHANNEL)) 

#define  WATT_CALL_DURATION    ((opintrpttype  ()  ==  OPC_INTRPT_SELF)  &&  \ 

(opintrptcode  ()  =  AMSC_TGEN_WArr_CALL_DURATION)) 

#defme  END_SIMULATION      ((opintrpttype  ()  ==  OPC_INTRPT_ENDSIM)) 

#define  NEIGHBOR_NOTIFY      ((opjntrpttype  ()  =  OPC_INTRPT_REMOTE)  &&       \ 

(opjntrptcode  ()  =  AMSC_NEIGHBOR_NOTIFY)) 

#define  NOTIFY_COMPLETE     (ams_neighbor_notify_is_complete  (nbr_data_ptr)  =  OPC_TRUE) 

/*  These  are  self  interrupt  codes.  */ 

#define    BADD_CALL_SCH_START  0 

#define  AMSC_TGEN_CALL_END  1 

#define  AMSC_TGEN_DATA_GEN  2 
#define  AMSC_TGEN_WAIT_CALL_DURATION    3 

#define  BADD_CALL_SCHEDULER  4 

#define  BADD_CALL_RESCHEDULE  5 

#defme  BADD_CHECK_CHANNEL  6 

#define  MAX_CHANNELS  1024 

#define  MAXSIZE  11 

/*  The  scheduler  process  will  output  trace  information  if  these  conditional  are  true.  */ 
#define  LTRACE_ ACTIVE  (debug_mod&  &&  \ 

(op_prg_odb_ltrace_active  ( "  ams  " )  II  \ 

op_prg_odb_ltrace_active  ( " ams_t  ra f " )  II  \ 

op_prg_odb_ltrace_active  ( ■  ams_t  ra  f _gen " ))) 

#defme  LTRACE_CONNECT_ACTIVE      (op_prg_odb_ltrace_active  ( ■  connect ")) 

#define  LTRACE_CALL_SCHEDULER_  ACTIVE     (opprgodbjtraceactive  (-call_scheduler")) 

#define  LTRACE_CALL_SCH_ACTrVE  (op_prg_odb_ltrace_active  (-call_sch")) 

#define  LTRACE_CALL_DISP_ACTP/E        (opprgodbjtraceactive  ("cal  l_disp")) 


197 


Process  Model  Report:  baddcallschedulernumberbased 

|  TueJun  17  10:55:33  1997 

|  Page  7  of  35 

80 


85 


#defineL'ERACE_CALL_CHANNELS_ACTIVE       (op_prg_odb_ltrace_active  ("call_channels-)) 

#define  LTRACE_CALL_TIMER_  ACTIVE        (opprgodbltraceactive  ( "ca  1  l_t  imer  ■)) 

#defineLTRACE_CALL_RESCHEDULER_  ACTIVE        (op_prg_odb_ltrace_active  ("call_rescheduler-)) 

/*  Function  declarations.  *l 

void  badd_caIl_sch_nbr_intrpt_proc  (); 

void  badd_caIl_sch_spurious_signal_handle  (); 

void  badd_call_sch_list_print  (); 

void  badd_call_sch_error  (); 


State  Variable  Block 

int                                   \debug_mode; 

int                                   \packet_size; 

int                                   \dest_addr; 

int                                   \AAL_type; 

5 

int                                   \qos_class; 

int                                   \to_aal_stream_index; 

int                                   \lo_req_stream_index; 

int                                   \sch_channel_count; 

int                                 \number_calls_pending; 

10 

int                                 \max_calls_pending; 

double                             \avg_rate; 

double                             \channel_delay; 

double                             \trans_delay; 

double                           \time_to_next_scheduler. 

15 

double                             \end_sim_time; 

char                                 \pid_string  [128]; 

Objid                             \my_id; 

Objid                              \aal_moduIe_id; 

Objid                              \req_module_id; 

20 

List*                               \calls_pending; 

List*                               \calls_scheduled; 

List*                               \static_channels; 

FILE*                             \output_file; 

FILE*                             \output_calls; 

25 

Ici*                                 \aal_handle_iciptr; 

Evhandle                         \next_packet_arrival; 

Evhandle                         \call_end_intrpt; 

Distribution*                   \int_arrival_distptr; 

Distribution*                   \call_wait_distptr; 

30 

Distribution*                   \call_duration_distptr. 

AmsT_Traf_Contract*    Nrxaf_con_ptr; 

AmsT_Neighbor_Data*  \nbr_data_ptr. 

Badd_Sch_Mod_Data    \ScheduIer_Module; 

Badd_Channel_Desc*    \channel_ptr; 

35 

Temporarv  Variable  Block 

int                                     primitive; 

int                                   cd_packet_size; 

int                                   clark_dest_addr. 

int                                     calls_list_size; 

5 

int                                   index  =  0; 
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int 

channel_index; 

ml 

sch_channel_index; 

int 

check_chan_index ; 

int 

call_b't_rate; 

int 

call_compl_channel; 

int 

call_release_channel ; 

int 

total_channels  =  0; 

int 

channel_count  =  0; 

int 

value; 

int 

least_calis; 

int 

least_call  s_index ; 

int 

temp_intrpt_type; 

int 

temp_intrpt_code; 

int* 

int_ptr; 

int* 

channel_size_ptr; 

double 

peak_cell_rate; 

double 

cdv_tolerance; 

double 

int_arr_time; 

double 

call_wait_time; 

double 

call_duration; 

double 

event_time; 

double 

channel_compl_time; 

double 

temp_double; 

double 

temp.PCR; 

double 

time_enqueued; 

double 

time_dequeued; 

double 

time_in_queue; 

extern  int 

total_calls_requested; 

extern  int 

total_call  s_generated; 

extern  int 

total_calls_received; 

extern  int 

total_calls_active; 

extern  int 

max_calls_active; 

char 

string[ll]; 

Ici* 

if_iciptr; 

Ici* 

req_iciptr, 

Ici* 

call_iciptr; 

Ici* 

signal_iciptr; 

Ici* 

setup_iciptr; 

Ici* 

upper_handle_iciptr; 

Ici* 

check_channel_iciptr. 

Ici* 

channel_iciptr; 

Ici* 

sch_channel_iciptr; 

PTohandle 

call_gen_prohandle; 

Prohandle* 

call_gen_proptr. 

Evhandle 

this_event; 

Evhandle 

next_event; 

Evhandle 

scheduler_event; 

List* 

channel_listptr; 

List* 

sch_channel_li  stptr; 

FILE* 

input_file; 

Compcode 

channel_scheduled; 

Compcode 

sch_requested; 

AmsT_Traf_Contract*    tmp_traf_con_ptr; 
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Function  Block 

void 

badd_call_sch_nbr_intrpt_proc  (ndata_ptr,  ndesc_ptr,  stale_ptr) 

AmsT_Neighbor_Data*  ndata_ptr; 

AmsT_Neighbor_Desc*  ndesc_ptr; 

5 

void*                               state_ptr; 

{ 

AmsT_Neighbor_Verify_Desc       vdesc; 

int                                                  to_sw_stream_index; 

10 

/**  This  procedure  handles  a  neighbor  notification  event  in  an  AMS 

**/ 

/**  trafgen  specific  manner.  It  determines  the  neighbor's  object 

**/ 

/**  ID  and  type,  and  verifies  that  there  are  a  correct  number  of 

**/ 

/**  interconnections. 

**/ 

FIN  (badd_call_sch_nbr_intrpt_proc  (ndata_ptr,  ndesc_ptr,  state_ptr)); 

15 

/*  Switch  based  on  the  AMS  type. 

*/ 

switch  (ndesc_ptr->module_amstype) 

case  AMSC_MTYPE_AAL: 

20 

{ 

/*  Build  the  verify  desc  data  structure. 

*/ 

vdesc.mod_id                 =  my_id; 

vdesc.nbr_id                   =  ndesc_ptr->module_objid; 

vdesc.nbr_id_ptr             =  &aal_module_id; 

25 

vdesc.mod_name             =  "BADD  Call    Scheduler"; 
vdesc.nbr_name              =  "AAL"; 
vdesc.nbr_type                =  AMSC_MTYPE_AAL; 
vdesc.from_nbr_stnn_cnt                      =  1; 
vdesc.from_nbr_strm_index_ptr            =  OPC_NIL; 

30 

vdesc.to_nbr_strm_cnt                          =  1; 
vdesc.to_nbr_strm_index_ptr                 =  &to_aal_stream_index; 

/*  Verify  that  the  neighbor  has  the  correct 

*/ 

1*  characteristics. 

*/ 

35 

ams_neighbor_verify  (&vdesc); 

break; 

} 

40 

case  BADD_MTYPE_SCHEDULER_CLIENT: 

( 

/*  Build  the  verify  desc  data  structure. 

*/ 

vdesc.mod_id                  =  my_id; 

vdesc.nbr_id                    =  ndesc_pti->module_objid; 

45 

vdesc.nbr_id_pn             =  &req_module_id; 

vdesc.mod_name             =  "BADD  Call    Scheduler"; 

vdesc.nbr_name               =  "call_req"; 

vdesc.nbr_type                =  BADD_MTYPE_SCHEDULER_CLIENT; 

vdesc.from_nbr_strm_cnt                      =  1; 

50 

vdesc.from_nbr_strm_index_ptr            =  OPC_NIL; 
vdesc.to_nbr_strm_cnt                           =  1; 
vdesc.to_nbr_strm_index_ptr                  =  &to_req_stream_index; 

/*  Verify  that  the  neighbor  has  the  correct 

*/ 
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/*  characteristics.  */ 

/*  ams  neighbor  jyerify  (Jcvdesc);  */ 

break; 

} 

default: 

( 

/*  This  is  an  unexpected  neighbor  notification.  */ 

I*  Issue  error  message.  */ 

op_sim_end  ("Process    received  a   neighbor  notification    from   a   module", 

"of    an   unexpected   type.      Simulation  terminated  .",  OPC_NIL,  OPC_NIL); 

break; 


FOUT; 


void 
badd_call_sch_spurious_signal_handle  () 


Ici* 

if_iciptr; 

Ici* 

release_if_iciptr; 

int 

primitive; 

Ici* 

ll_handle_iciptr; 

Packet* 

pkptr; 

/*  This  procedure  handles  spurious  interrupts. 

I*  Only  three  types  of  spurious  interrupts  can  be  accepted.  All 

I*  others  must  result  in  an  op_sim_end  ().  These  three 

I*  interrupts  are: 

I*      I.  An  AAL  ESTAB  Ind. 

I*     2.  An  AAL  RELEASE  Con. 

I*      3.  A  packet  arrival. 

FIN  (badd_call_sch_spurious_signaI_handle  ()); 

if  ( AAL_CALL_SETUP) 

{ 

/*  This  is  a  signal  from  the  AAL. 

/*  Obtain  the  ICI  pointer. 
if_iciptr  =  op_intrpt_ici  (); 

/*  Obtain  the  primitive  from  the  ICI. 

op_ici_attr_get  (if_iciptr,  "primitive",  &primitive); 

/*  Obtain  the  'lower  layer  handle'  from  the  ICI. 

op_ici_attr_get  (ifjciptr,  "lower   layer  handle",  &ll_handle_iciptr); 


/*  Switch  on  the  'primitive' 
switch  (primitive) 


*/ 


case  AMSC_AAL_ESTAB_Ind: 

{ 

/*  This  is  an  'establish  indication'  from  the  AAL. 

if(LTRACE_ACTIVE) 


*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
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op_prg_odb_print_major  (pid_string,  "Received  spurious  AAL   ESTABLISH   Request    signal.' 
"Call    not    accepted.  ",  "Sending  AAL   RELEASE   Request    signal  .",  OPC_NEL); 


/*  Set  the  '  upper  layer  handle'  in  the  interface 

I*  1CI  for  the  'establish  indication'  signal,  since 

I*  the  lower  layer  expects  it  to  be  filled  in.  The 

I*  ICl  is  not  destroyed,  since  this  is  a  forced 

/*  interrupt  and  the  lower  layer  process  expects 

/*  to  obtain  the  handle  from  the  ICl  when  the 

I*  control  returns. 

op_ici_attr_set  (if_iciptr,  "upper   layer  handle" 


*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 


OPC.NIL); 


/*  Simply  send  an  AAL_RELEASE_Req  to  request  that  *l 

I*  the  connection  be  released.  *l 

release_if_iciptr  =  op_ici_create  (AMSC_INTERFACE_ICI); 
op_ici_attr_set  (release_if_iciptr,  "primitive",  AMSC_AAL_RELEASE_Req); 
op_ici_attr_set  (release_if_iciptr,  "  1  ower   1  ayer  hand  1  e " ,  H_handle_iciptr); 
op_ici_install  (release_if_iciptr); 

/*  Send  a  remote  interrupt  which  will  carry  the  ICl  to  the  AAL  module.  */ 
op_intrpt_schedule_remote  (op_sim_time  (),  AMSC_INTERFACE_SIGNAL,  aal_module_id); 

break; 

) 

case  AMSC_AAL_RELEASE_Con: 

{ 

/*  This  is  a  '  release  confirm'  from  the  AAL.  */ 

if(LTRACE_ACTIVE) 

( 

op_prg_odb_print_major  (pid_string,  "Received   spurious   AAL  RELEASE  Confirm  signal.", 

"This    in   response   to   AAL   RELEASE   Request   terminating   spurious   connect  ion. ",  O 
} 


/*  This  is  a  response  to  our  earlier  'release 
I*  request'  which  was  a  response  to  the 
I*  spurious  '  estab  indication  . 
I*  Do  nothing  other  than  destroy  the  ICl. 
op_ici_destroy  (if_iciptr); 

break; 

} 


*/ 
*/ 
*/ 
*/ 


default: 


/*  This  is  some  other  completely  unexpected 
I*  signal.  Issue  error  message  and  terminate 
I*  simulation. 
op_sim_end  ("In  badd_call_scheduler, 


else  if  (opintrptrype  ()  =  OPC_INTRPT_STRM) 

{ 

/*  This  is  a  spurious  packet  arrival.  The  amstrafgen 

I*  just  destroys  this  packet. 


*/ 
*/ 
*/ 
Received   unexpected   signal. 
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if(LTRACE_ACTIVE) 
{ 
op_prg_odb_print_major  (pid_string,  "Received  spurious   DATA  packet. 

"Destroying   the  packet .",  OPC_NIL); 
} 


/*  Get  the  packet  fromt  the  stream  and  destroy  it. 
pkptr  =  op_pk_get  (op_intrpt_strm  ()); 
op_pk_destroy  (pkptr); 

} 


*/ 


else 


( 

/*  This  is  some  other  completely  unexpected 

I*  interrupt.  Issue  error  message  and  terminate 

I*  simulation. 

op_sim  end  ("Received  unexpected   interrupt. 

} 


FOUT; 


void 

badd_call_sch_list_print  (calls_list) 

List*        calls_list; 

{ 

int     list_size; 

nit    index  =  0; 

int    list_packet_size; 

int    list_dest_addr; 

int     list_qos_dass; 

int    list_AAL_type; 

double  list_bit_rate; 

double  list_int_arr_time; 

double  list_call_wait_time; 

double  list_call_duration; 

double  list_peak_cell_rate; 

Ici*    req_iciptr; 

/*  This  procedure  will  print  all  the  calls_descs  in  the  calls _pending  list  *l 
FIN(badd_call_schJist_print(callsJist)); 

list_size  =  op_prg_list_size(calls_list); 

if  (list_size  =  0) 


printf(* 


Attempting  to  print  empty  call_list .  \n"); 


} 


for  (index  =  0;  index  <  list_size;  index++) 
{ 
req_iciptr  =  (Ici*)  op_prg_list_access  (calls_list,  index); 

if  (req_iciptr  =  OPC_NIL) 

badd_call_sch_erTor(  "Unable  to  <jet    req_iciptr   from  calls_pending   list .  ",  OPC_NIL,  OPC_NIL); 

if  ((op_ici_attr_get  (req_iciptr,  "interarrival   time",  &list_int_arr_time)  =  OPC_COMPCODE_FAILURE)  II 
(opiciattrjget  (req_iciptr,  "packet   size",  &list_packet_size)  =  OPC_COMPCODE_FAJLURE)        II 
(op_ici_attr_get  (req_iciptr,  "call   wait    time",  &list_call_wait_ume)  =  OPC_COMPCODE_FAE.URE)  II 
(opiciattrget  (req_iciptr,  "call   duration",  &list_call_duration)  ==  OPC_COMPCODE_FATLURE)     II 
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(op_ici_attr_get  (reqjciptr,  "dest   addr " ,  &list_dest_addr)  =  OPC_COMPCODE_FAJLURE)             II 

(op_ici_attr_get  (req_iciptr,  "QoS  class",  &list_qos_class)  =  OPC_COMPCODE_FAILURE)             II 

(opjciattr^get  (req_iciptr,  " AAL  type " ,  &Iist_AAL_type)  =  OPC_COMPCODE_FAILURE)               II 

235 

(opjciattrjget  (reqjciptr,  "peak  cell    rate",  &list_peak_cell_rate)==  OPC_COMPCODE_FAILURE)) 

badd_call_sch_error(  "Unable   to   get   values    from  call_req   iciptr",  OPC_NIL,  OPC_NIL); 

printf("In  badd_call_scheduler  .print  ing   cal  ls_pending    list:    int_arr_time   =    %f.\n", 

list_int_arr_time); 

240 

printf("In   badd_call_scheduler  .print  ing   cal  ls_pending   list:    packet_size   =   %d.\n", 

list_packet_size); 

printf("In  badd_call_scheduler. printing  cal  ls_pending   list:    call_wait_time   =   %f.\n". 

list_call_wait_time); 

printf("In  badd_call_scheduler  .print  ing   cal  ls_pending    list:    call_duration   =    %f.\n", 

245 

list_call_duration); 

printf("In  badd_call_scheduler  .print  ing  cal  ls_pending    list:    dest_addr  =   4d.\n", 

list_dest_addr); 

printf("In  badd_call_scheduler  .printing  cal  ls_pending   list:    qos_class   =   %d.\n", 

list_qos_class); 

250 

printf("In  badd_call_scheduler  .printing   cal  ls_pending    list:    AAL_type   =   %d.\n", 

list_AAL_type); 

printf("In  badd_call_scheduler .printing  calls_pending   list:    peak_cell_rate   =   %f.\n". 

list_peak_cell_rate); 

printf("In  badd_call_scheduler .printing  calls_pending    list:    bit_rate   =   %f.\n", 

255 

list_peak_cell_rate  *  424); 

}  /*  End  for  loop  *l 

FOUT; 

i 

260 

) 

void 

badd_call_sch_error  (msgO,  msgl,  msg2) 

char*               msgO; 

char*               msgl; 

265 

char*               msg2; 

I 

/**  Prim  an  error  message  and  exit  the  simulation.  **/ 

FIN  (badd_call_sch_error  (msgO,  msgl,  msg2)); 

270 

op  sim  end  ("Error    in   badd_call_scheduler  process:", 

msgO,  msgl,  msg2); 

FOUT; 

} 

275 

Diagnostic  Block 


/*  Display  connection  information,  if  requested.  */ 
if  (LTRACE_CONNECT_ACrrVE) 

{ 

/*  Prim  information.  */ 

ams_neighbor_data_print  (nbr_data_ptr,  ams_neighbor_desc_print_noop); 
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forced  state    INIT 

attribute 

value 

tvpe 

default  value 

name 

enter  execs 
exit  execs 
status 

INIT 

(See  below.) 

(empty) 

forced 

string 
textlist 
textlist 
toggle 

St 

(empty) 
unforced 

enter  execs    INIT 

/*  Determine  the  initial  values  of  the  state  variables  and  set  up                                    *l 

/*  the  initial  state  of  this  instantiation  of  the  ams  traf  gen                                            */ 

/*  process.                                                                                                                       */ 

5 

/*  Obtain  the  object  ID  of  this  process'  parent  module.                                                 *l 
my_id  =  op_id_self  (); 

/*  Determine  whether  or  not  the  simulation  is  in  debug  mode.                                         */ 

10 

debug_mode  =  op_sim_debug  (); 

/*  Initialize  the  AAL  module  object  ID  to  NULL  value.                                                  */ 

aal_moduIe_id  =  OPC_OBJID_NULL; 

req_module_id  =  OPC_OBJBD_NULL; 

15 

/*  Create  a  list  for  storing  the  calls  as  they  arrive  */ 
calls_pending  =  op_prg_list_create(); 

/*  Read  the  static  channels  input  file  and  create  lists  accordingly.  *l 
stalic_channels  =  op_prg_list_create(); 

20 

calls_scheduled  =  op_prg_list_create(); 

/*  Open  the  channel  definition  file.  *l 

if  ((input_file  =  fopen(" /us r /work/bent on/ input_channe Is",  "r")) 

=  NULL) 

25 

{ 
badd_call_sch_error(" Problem  opening  static   channel    definition    file.", 

OPC_NIL,  OPC_NIL); 

i 

30 

t 

if  (fgets  (  string,  MAXSIZE,  input_file  )  !=  NULL) 

if  (LTRACE_C  ALL_CHANNELS_ACTIVE) 

pnntf("In   badd_call_sch.  init ;    string   is   %s  .  \n",  string); 

if  (get_digit(string,  &value)  =  OPC_COMPCODE_FATLURE) 

I 

35 

badd_caII_sch_error  ("Invalid  number  of   static   channels.", 
OPC_NIL,  OPC_NIL); 
) 

toiaJ_channels  =  value; 
if  (LTRACE_CALL_CHANNELS_  ACTIVE) 

40 

( 

pruitf(":r,    badd_call_sch.  load_stat ic_channels    function   after   reading 

channel "); 

pnntf ( "   count  ;total_channels   =   %d.  \n",  total_channels); 

1 

45 

1 

if  (toiaJ_channels  >  MAX_CHANNELS) 

( 
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badd_call_sch_error( "Requested   virtual    channels   exceeds   maximum  allowed.", 
OPC_NEL,  OPC.NIL); 


while  ((fgets  (  string,  MAXSIZE,  input_file  )  !=  NULL)  && 
(channel_count  <  total_channels)) 

{ 
if  (LTRACE_CALL_CHANNELS_  ACTIVE) 
( 

printf("In   badd_call_sch.  init ,    reading   each   channel    size;"); 

printf("   channel_count    =   %d.  \n",  channel_count); 

printf("In   badd_call_sch.  init ,-    string  value    is   %s  .  \n",  string); 

} 

if  (get_digit(string,  &value)  =  OPC_COMPCODE_FATLURE) 

{ 
badd_call_sch_eiTor  ("  Invalid  number   for  static  channels.", 
OPC.NIL,  OPC_NIL); 

} 

if  (value  >  8000000) 

{ 

badd_call_sch_error  ( 
} 

channel_ptr  =  (Badd_Channel_Desc*)  op_prg_mem_alIoc(sizeof(Badd_Channel_Desc)); 
if  (channel_ptr  =  OPC_NIL) 
{ 

badd_call_sch_error( "Unable   to   allocate  memory   for  channel    definition.", 
OPC_NIL,  OPCJMIL); 

} 

channel_ptr->ch_capacity  =  value; 
channei_ptr->ch_calls_sch  =  -1; 
cbannel_ptr->ch_calls_compl  =  0; 
channeI_ptr->ch_compl_time  =  0.0; 

op_prgJist_insert(static_channels,  channel_ptr,  OPC_LISTPOS_TAIL); 
if  (LTRACE_C  ALL_CHANNELS_ACTrVE) 

{ 
printf("In  badd_call_sch.  init ,    channel    value  saved   =   %d .  \n",  channel_ptr->ch_capacity); 


/*  Create  a  list  to  store  the  calls  for  this  channel  */ 
channel_listptr  =  op_prg_list_create(); 
if  (channel.listptr  =  OPC_NIL) 
{ 
badd_call_sch_error( "Unable   to   allocate  memory   for  channel    list. 
OPC_NIL,  OPC_NIL); 
) 

op_prg_list_insert(calls_scheduled,  channeljistptr,  OPC_LISTPOS_TAIL); 
channel_count  =  channel_count  +  1; 

} 

if  (LTRACE_CALL_CHANNELS_  ACTIVE) 

{ 
channel_count  =  op_prg_list_size(static_channels); 

printf("In  badd_call_sch.  init ,    elements    in   static   channels    "); 

printf("list   =  %d.  \n",  channel_count); 

channel_count  =  op_prg_list_size(calls_scheduled); 

printf("In  badd_call_sch.  init ,    elements    in   sch_channels    "); 

printf("list   =  %d.  \n",  channel_count); 
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fclose(input_file); 

/*  Open  file  for  storing  call  timer  information.  *l 

if  ((output_file  =  fopen("/usr/work/benton/output_cal  l_times_f  ifo",  "w")) 

=  NULL) 
( 
badd_call_sch_error(" Problem  opening  output_call_times    file.", 
OPC_NIL,  OPC_NIL); 
} 

/*  Write  a  file  formal  statement  as  the  first  line  in  the  file.  */ 

fputs("File   Format:    Channel    Enqueued_Time   Dequeued_Time   Time_In_Queue   PCR\n" 
output_file); 

/*  Open  file  for  storing  calls  completed  information.  */ 

if  ((output_calls  =  fopen( "  /usr /work/benton/output_ca  1  l_completed_f  ifo",  " w" )) 

=  NULL) 

( 
badd_call_sch_error(" Problem  opening  output_call_compleced  file.", 
OPC.NIL,  OPC.NIL); 


/*  Write  a  file  format  statement  as  the  first  line  in  the  file.  *l 

fputs("File  Format:    Channel    Time_completed   PCR .  \n",  output_calls); 

sch_channel_count  =  op_prg_list_size(static_channels); 

/*  Generate  P1D  display  string.  *l 

sprintf  (pid_string,  "badd_call_scheduler   PID    (*d)  ",  op_pro_id  (op_pro_seIf  ())); 

/*  Obtain  and  send  out  neighbor  information.  *l 

nbr_data_ptr  =  ams_neighbor_data_build  (); 

ams_neighbor_notify  (nbr_data_ptr,  AMSC_MTYPE_AAL_CLIENT); 

if  (LTRACE_CALL_SCHEDULER_ACTIVE) 

{ 
printf("In  badd_call_scheduler .  init :    print   neighbor   info.\n"); 
ams_neighbor_data_print  (nbr_data_ptr,  ams_neighbor_desc_print_noop); 


/*  This  Scheduler  Module  is  attached  to  any  process  spawned  by  *l 

I*  this  badd_call_requestor  process.  */ 

l*Scheduler  Module  =  (Badd_Sch_Mod_Data*)  op_prg_mem_alloc(sizeof(Badd_Sch_Mod_Data));  */ 

op_pro  modmem_install(&Scheduler_Module); 

/*  Initialize  the  model  parameter  attributes.  */ 

op_ima_obj_attr_get  (my_id,  "scheduler  delay",  &time_to_next_scheduler); 
op_ima_obj_attr_get  (my_id,  "transmission  delay",  &trans_delay); 
op_ima_obj_attr_get  (my_id,  "channel   delay",  &channel_delay); 
op_ima_obj_attr_get  (my_id,  "calls  pending",  &max_calls_pending); 

/*  Initialize  the  end_sim_time  varaible  */ 

op_ima_sim_attr_get(OPC_IMA_DOUBLE,  "duration",  &end_sim_tinie); 
/*  printf["end_simjime  -  %f.\n",  end_sim_time);  *l 

if  (LTRACE_CALL_SCHEDULER_ACTIVE) 

( 

printf("In   badd_call_scheduler .  init   state:    Leaving    init   state.    \n"); 
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/*  Ams_traf_gen  expects  either  a  neighbor  notification  interrupt,  */ 

/*  or  a  spurious  signal.  */ 

if  (NEIGHBOR_NOTIFY) 
{ 

/*  This  is  a  'neighbor  notify'  signal.  */ 

if(LTRACE_ACTIVE) 
{ 
op_prg_odb_print_major  (pid_string,  "Received  neighbor  notification. ",  OPC_NIL); 


/*  Handle  the  neighbor  notification.  */ 

ams_neighbor_interrupt_handle  (nbr_data_ptr,  badd_call_sch_nbr_intrpt_proc,  OPC_NIL); 


else 


I*  This  is  a  spurious  interrupt.  Handle  appropriately. 
badd_call_sch_spurious_signal_handle  (); 
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/*  Compare  the  number  of  calls  in  the  calls _pending  list.  */ 
/*  If the  number  exceeds  the  max _calls_p ending,  schedule    *l 
I*  a  call  to  execute  the  scheduler.  */ 

number_calls_pending  =  op_prg_list_size(calls_pending); 
if  (number_calls_pending  >  max_calls_pending) 

op_intrpt_schedule_self  (op_sim_time  ().  BADD_CALL_SCHEDULER); 

/*  Schedule  the  next  scheduling  event  */ 
if  (number_calls_pending  >  0) 

op_intrpt_schedule_self  (op_sim_time  ()  +  time_to_next_scheduler,  BADD_CALL_SCHEDULER); 


exit  execs    dispatch 


10 


15 


temp_intrpt_type  =  op_intrpt_type(); 
temp_intrpt_code  =  op_intrpt_code(); 

if  (LTRACE_CALL_DISP_ACTIVE) 

{ 
printf("  In   badd_call_scheduler. dispatch 
printf("In  badd_call_scheduler. dispatch 
printf("  In   badd_call_scheduler  .dispatch 

}  /*  Endif(LTRACE_CALL_DlSP_ACTNE)*l 

if  (SIGNAL) 
{ 

signal_iciptr  =  op_intrpt_ici(); 

if  (signal_iciptr  =  OPC_NIL) 

badd_call_sch_error( "Unable   to   get   signal_iciptr . ' 

if  (LTRACE_CALL_DISP_ACTIVE) 
{ 
op  ici  print(signal_iciptr); 


received   SIGNAL.  \n"); 

intrpt_type   =   %d.  \n",  temp_intrpt_type); 

intrpt_code  =   %d.  \n",  temp_intrpt_code); 


OPC_NIL,  OPC_NIL); 
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)  /*  Endif(LTRACE_CALL_DISP_ACTIVE)*l 
op_ici_attr_get(signal_iciptr,  "primitive",  &primitive); 
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sch_channel_iciptr  =  op_intrpt_ici(); 

if  ((op_ici_attr_get  (sch_channel_iciptr,  -channel   number",  &sch_channel_index)  =  OPC_COMPCODE_FAILURE)) 
badd_call_sch_eiTOr( " I n   start_call:    unable  to  get   values   from  sch_channel    iciptr", 
OPC_NIL,  OPC_NIL); 

/*  Destroy  the  ici  to  recover  space,  Garbage  collection.  *l 
op_ici_destroy(sch_channel_iciptr); 

if  (LTRACE_CALL_SCH_ACTIVE) 

printf("In  call   scheduler  .start_call :    sch_channel    index   =   %d.  \n",  sch_channel_index); 
sch_channel  Jistptr  =  (List*)  op_prg_list_access(calls_scheduled,  sch_channel_index); 
call_iciptr  =  (Ici*)  op_prg_list_remove(sch_channe!_listptr,  OPC_LISTPOS_HEAD); 


if  (calljciptr  =  OPC_NIL) 

badd_call_sch_error( "In  start   call, 


unable  to   get   call_iciptr   from  cal  ls_list . ",  OPC_NIL,  OPC_NIL); 


if  ((op_ici_attrjget  (calljciptr, 
(op_ici_attr_get  (call_iciptr,  " 
(op_ici_attr_get  (call_iciptr,  " 
(op_ici_attrjget  (calljciptr,  " 
(op  Jci_attr_Jget  (call_iciptr,  " 
(op_ici_attr_get  (calljciptr,  " 
(opJci_attr_get  (calljciptr,  " 
(op_ici_attr_get  (calljciptr,  ■ 
(op_ici_attr_get  (calljciptr,  " 
badd_call_sch_error(  "Unable 


■  interarrival  time",  &int_arr_time)  =  OPC_COMPCODEJ=AILURE)  I 
packet   size",  &packet_size)  =  OPC_COMPCODE  J^AILURE)        II 
call   wait  time",  &call_wait_time)  =  OPC_COMPCODEJ^ATLURE)  II 
call   duration",  &caU_duration)  =  OPC_COMPCODE_FAILURE)     II 
dest   addr",&dest_addr)  =  OPC_COMPCODE_FAILURE)  II 

QoS  class",  &qos_class)  =  OPC.COMPCODEJ^ATLURE)  II 

AAL  type",&AAL_type)  =  OPC_COMPCODE_FAE.URE)  II 

peak  cell   rate",  &peak_cell_rate)  =  OPC_COMPCODEJ^AILURE)  II 
t  ime   queued ■ ,  &time_enqueued)  =  OPC_COMPCODE J^AILURE)) 
to   get   values    from  call_req    iciptr",  OPCJMIL,  OPCJSIL); 


if  (LTRACE_C  ALL  _SCHEDULER_ACTIVE) 


printf("  In  badd_call_scheduler .  start_call 
printf("In  badd_call_scheduler. start _ca  11 
printf("In  badd_call_scheduler.start_call 
printf("In  badd_call_scheduler .start_call 
printf( "  In  badd_ca  1  l_scheduler .  s tart_ca  1 1 
printf("In  badd_call_scheduler .start_call 
printf( "In  badd_ca  1  l_scheduler . start_ca  1 1 
printf( "In  badd_ca  1  l_scheduler . start_ca  1 1 
/*  End  if(LTRACE_CALL_SCHEDULER_ACTrVE)  *l 


int_arr_time   =   %f .  \n",  int_arr_time); 
packet_size  =   %d.  \n",  packet_size); 
call_wait_time   =   %f .  \n",  call_wait_time); 
call_duration   =   % f  .  \ n " ,  call_duration); 
dest_addr   =   %d  .  \n",  dest_addr); 
qos_class   =   %d  .  \n",  qos_class); 
AAL_type   =    %d .  \n",  AAL_type); 
peak_cell_rate   =   %f  .  \n",  peak_cell_rate); 


if  (opiciattrset  (calljciptr,  "channel   assigned",  sch_channe!Jndex)  =  OP^COMPCODEJ^ATLURE) 
badd_call_sch_error(  "Unable   to   set    sch_channel_index   in   cal  l_iciptr",  OPCJVIL,  OPCJMIL); 

time_dequeued  =  op_sim_time(); 
timejn_queue  =  time_dequeued  -  time_enqueued; 

/*  Write  queue  times  to  the  call  timer  output  file.  */ 

fprintf(output_file,  "%d  %f   %t   %t   %f  \n",  sch_channeljndex,  time_enqueued,  time_dequeued, 
time_in_queue,  peak_cell_rate); 

/*  Update  program  counter  *l 
total_calls_generated  =  total_calls_generated  +  1; 
total  calls  active  =  total  calls  active  +  1: 
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if  (total_calIs_active  >  max_calls_active) 
max_calls_active  =  total_calls_active; 

if  (LTRACE_CALL_SCHEDULER_ACTIVE) 
{ 

printf("In   badd_cal  l_scheduler ,    start;    starting   call    to   dest    %d.\n", 
dest_addr); 
)  /*  if (LTRACECALLJCHEDULER  ACTIVE)  *l 

/*  Spawn  a  child  process  to  generate  the  call  data  */ 

cal!_gen_prohandle  =  op_pro_create("clark_badd_call_generator",  OPC_NIL); 

if  (op_pro_valid(call_gen_prohandle)  =  OPC_FALSE) 

{ 
badd_cal)_sch_error( "Unable  to  create  call  generator  process",  OPC_NIL,  OPC_NIL); 

} 

if  (LTRACE_CALL_SCHEDULER_ACTIVE) 

{ 
printf("In  badd_call_scheduler,    start;    invoking   call   generator.  \n"); 
printf("In   badd_call_scheduler  .start :    call_iciptr   =   %x.  \n",  call_iciptr); 
printf("ln  badd_call_scheduler.start_call ;   md_aal_module_id  =   %d.\n",  Scheduler_Module.md_aaI_module_id): 

}  /*  if (LTRACECALL  SCHEDULER  ACTIVE)  */ 

if  (LTRACE_CALL_TIMER_ACTrVE) 

printf("In   badd_call_sch. start   call:    current   time   =   %f  .  \n",  op_sim_time()); 

/*  When  invoking  the  process,  pass  in  the  call  desc  */ 

if  (op_pro_invoke(caU_gen_prohandle,  call_iciptr)  =  OPC_COMPCODE_FATLURE) 

{ 
badd_call_sch_error(  "Unable   to    invoke  call   generator   process",  OPC_NIL,  OPC_NIL); 
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signal_iciptr  =  op_intrpt_ici(); 

if  (signal_iciptr  =  OPC_NIL) 

badd_caI!_sch_error(  "Unable  to  get   signal_iciptr  .  -,  OPC_NIL,  OPC_NIL); 

if  (LTRACE_CALL_SCHEDULER_ACTI  VE) 

{ 

printf("In   badd_call_scheduler .send  data:    restarting  call_gen  An"); 
op_ici_print(signal_iciptr); 

}  /*  Endif(LTRACE_CALL_SCHEDULER_ACTrVE)*l 

if  (op_ici_attrjget(signal_iciptr,  "upper   layer  handle",  &upper_handle_iciptr)  =  OPC_COMPCODE_FAILURE) 
badd_call_sch_error(  "Unable  to  get  upper  layer  handle.  *,  OPC_NIL,  OPC_NEL); 

if  (op_ici_attr_get(upper_handle_iciptr,  "cal  l_gen_prohandle",  &call_gen_proptr)  =  OPC_COMPCODE_FAJLURE) 
badd_call_sch_error(  "Unable   to   get   call_gen  prohandle. ",  OPC_NIL,  OPC_NIL); 

if  (LTRACE_C  ALL_TIMER_ACTrVE) 

printf("In   badd_call_sch.  send   data:    current   time   =   %t .  \n",  op_sim_time()); 

if  (op_pro_invoke(*call_gen_proptr,  signal_iciptr)  =  OPC_COMPCODE_FATLURE) 

( 
badd_call_sch_error(" Unable   to   restart   call_gen  process",  OPC_NIL,  OPC_NIL); 
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if  (signaljciptr  =  OPC.NIL) 

badd_call_sch_error( "Unable   to   get    signal_iciptr  . ",  OPC_NIL,  OPC_NIL); 

if  (LTRACE_CALL_SCHEDULER_ACTIVE) 

{ 

printf("In   badd_call_scheduler  .cail_complete  :    restarting   cal  l_gen  .  \n  "); 
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op_ici_print(signal_iciptr); 

}  /*  Endif(LTRACE_CALLJCHEDULER_ACW/E)*l 

total_calIs_received  =  total_calls_received  +  1; 
total_calls_active  =  total_calls_active  -  1; 

if  (op_ici_attr_get(signal_iciptr,  -upper   layer  handle",  &upper_handle_iciptr)  =  OPC_COMPCODE_FAILURE) 
badd_call_sch_error( -Unable  to  get   upper  layer  handle.  -,  OPC_NIL,  OPC_NIL); 

if  (op_ici_attrjget(signaJ_iciptr,  "traffic  contract ",  &tmp_traf_con_ptr)  =  OPC_COMPCODE_FATLURE) 
badd_call_sch_eiTor(  "Unable   to  get    traffic   contract .",  OPC_N]L,  OPC_NIL); 

if  (op_ici_attr_get(signal_iciptr,  ■badd_call_gen_channel_id",  &call_compl_channel)  ==  OPC_COMPCODE_FAILURE) 
badd_call_sch_en-or( "Unable   to   get   call_gen  prohandle. ",  OPC_NIL,  OPC_NIL); 

/*  Write  completion  lime  and  PCR  to  the  calls  completed  output  file.  *l 

temp_PCR  =  tmp_traf_cxni_ptr->calling_ctd.src_traf_desc.pcr; 

fprii)tf(output_calls,  "%d   %f   %f  \n",  call_compl_channel,  op_sim_time(),  temp_PCR); 

channel_pD:  =  (Badd_Channel_Desc*)  op_prg_list_access(static_channels,  call_compl_channeI); 
channel_ptr->ch_calls_sch  =  channel_ptr->ch_calls_sch  -  1; 
channel_ptr->ch_calIs_compl  =  channel_ptr->ch_calls_compl  +  1; 

if  (op_ici_attr_get(upper_handle_iciptr,  "cal  l_gen_prohandle",  &call_gen_proptr)  =  OPC_COMPCODE_FATLURE) 
badd_caIl_sch_error("Unable  to   get   call_gen  prohandle. ",  OPC_NIL,  OPC_NIL); 

if  (LTRACE_CALL_TIMER_ACTrVE) 

printf("In   badd_call_sch.call   complete:    current   time   =   %f .  \n",  op_sim_time()); 

if  (op_pro_invoke(*caU_gen_proptr,  signal_iciptr)  =  OPC_COMPCODE_FATLURE) 
{ 
badd_call_sch_error( -Unable   to   restart    call_gen   process  ",  OPC_NIL,  OPC_NIL); 
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if  (signaljciptr  =  OPC_NIL) 

badd_caIl_sch_error( "Unable   to   get    signal_iciptr  . ",  OPC_NIL,  OPC_NIL); 

if  (LTRACE_C  ALL_SCHEDULER_ACTIVE) 
{ 

printf("In  badd_call_scheduler  .call_released:    restarting  call_gen.  \n"); 

op_ici_print(signal_iciptr); 

)  /*  End  if(LTRACE_CALLJCHEDULER_ACTlVE)  *l 

if(op_ici_attr_get(signal_iciptr,  -upper    layer  handle",  &upper_handle_iciptr)  =  OPC_COMPCODE_FATLURE) 
badd_call_sch_error( "Unable   to   get    upper   layer  handle. ",  OPC.NIL,  OPC_NIL); 

if  (op_ici_attr_get(signal_iciptr,  "badd_call_gen_channel_id\  &call_release_channel)  =  OPC_COMPCODE_FAILURE) 
badd_calI_sch_error( "Unable   to   get    call_gen  call_release_channel .  ",  OPC.NIL,  OPC_NIL); 

channel_ptr  =  (Badd_Channel_Desc*)  op_prg_list_access(static_channels,  call_release_channel); 
channel_ptr->ch_calls_sch  =  channel_ptr->ch_calls_sch  -  1; 

if  (op_ici_attrjget(upper_handieJciptr,  "cal  l_gen_prohandle",  &call_gen_proptr)  =  OPC_COMPCODE_FATLURE) 
badd_call_sch_error( "Unable   to   get    call_gen  prohandle.  ",  OPC_NIL,  OPC_NIL); 

total_calls_active  =  total_calls_active  -  1; 

if  (op_pro_invoke(*caU_gen_proptr,  signal_iciptr)  =  OPC_COMPCODE_FATLURE) 

{ 
badd_call_sch_error( ■  Unable   to   restart    call_gen   process  ",  OPC_NIL,  OPC_NIL); 
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/*  77ii.y  Scheduler  Module  is  attached  to  any  process  spawned  by  *l 
I*  this  badd  call _scheduler  process.  */ 

op_pro_modmem_install(&Scheduler_Module); 
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/*  Pass  the  neighbor  information  to  all  children  processes.      */ 
Scheduler_Module.md_neighbor_data_ptr  =  nbr_data_ptr, 
Scheduler_Module.md_aal_module_id  =  aal_moduIe_id; 
Sch.eduler_Module.md_to_aal_stream_index  =  to_aa]_stream_index; 
Scheduler_Module.md_calls_pending_ptr  =  calls_pending; 
Scheduler_Module.md_channel_delay  =  channel_delay; 
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/*  This  is  a  spurious  interrupt.  Handle  appropriately. 

printf("Bad   signal    received  by  badd_call_scheduler .  \n"); 
badd_calI_sch_spurious_signal_handle  (); 
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/*   Print  Information  during  testing   */ 

pnntfl  ■  :al  Is   currently  active   is   %d  .  \n".  total_calls_active); 

pnntffKax   cails   active    in  this    run  was   %d . \n",  max_calls_active); 

calh_lisi_size  =  op_prg_list_size(calls_pending); 
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printf("Cal  Is    remaining   in  the  calls_pending   list    at   termination    =   %d.  \n",  calls_list_size); 

printf( "  Ca  1 1  s    remaining   in   the  calls_scheduled    lists   at    terminat  ion.  \n"); 

time_dequeued  =  end_sim_time; 

for  (channel_index  =  0;  channel_index  <  sch_channel_count;  channel_index++) 
{ 

channel_ptr  =  (Badd_Channel_Desc*)  op_prg_list_access(static_channels,  channel_Lndex); 

calls_list_size  =  channel_ptr->ch_calls_sch; 

call_compl_channel  =  channel_ptr->ch_calls_compl; 

channeI_compl_time  =  channel_ptr->ch_compl_time; 

printf("  Channel    %d:    calls   compl    =   %d,    calls   remaining   =   %d,    completion   time   =   %f.\n" 

channel_index,  call_compl_channel,  calls_list_size,  channel_compl_time); 

channel_listptr  =  (List*)  op_prg_list_access(calls_scheduled,  channel_index); 

for  (sch_channel_index  =  0;  sch_channel_index  <  calls_list_size;  sch_channel_index++) 
{ 
call_iciptr  =  (Ici*)  op_prg_list_access(channeI_listptr,  sch_channel_index); 

if  ((opiciattrjget  (calljciptr,  ■  t ime  queued ",  &time_enqueued)  ==  OPC_COMPCODE_FATLURE)) 
badd_call_sch_error( " I n  End  Sim:   unable  to  get  values   from  call_req  iciptr", 
OPC_NIL,  OPC.NIL); 

time_in_queue  =  time_dequeued  -  time_enqueued; 

/*  Write  queue  limes  to  the  call  timer  output  file.  */ 

fprintf(output_file, -%d   %f   %f  %f  \n",  channel_index,  time_enqueued,  0.0,  0.0); 
/*        fprintfioutputjile,  "%d  %f%f%f\n",  channel  Jndex,  time _enqueued,  lime  dequeued, 
I*  time  in  queue);  *l 


if  (LTRACE_CALL_SCH_  ACTIVE) 
{ 
badd_call_sch_list_print(channel_listptr); 


/*  Close  the  Output  files.  *l 

fclose(output_file); 

fclose(output_calls); 

badd_call_sch_error( •  Ending   simulation    in  badd_call_scheduler.End   Sim.  \n",  OPC_NIL,  OPC_NIL); 
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/*  A  calljrequesl  arrived  from  the  call  requestor  above.  */ 
/*  Must  capture  the  call  request  information  from  the  */ 
/*  IC1  and  store  the  call  in  the  call_pending_list         *l 

req_iciptr  =  op_intrpt_ici(); 

if  (req_iciptr  ==  OPC.NIL) 

badd_call_sch_error( -Unable   to   get    call_req   iciptr. ",  OPC_NIL,  OPC_NIL); 


if  ((op_ici_attr_get  (req_iciptr, 
(op_ici_attr_get  (req_iciptr, 
(op_ici_attr_get  (req_iciptr, 
(op_ici_attr_get  (req_iciptr, 
(op_ici_attr_get  (req_iciptr, 
(op_ici_attr_get  (req_iciptr, 
(op_ici_attr_get  (req_iciptr, 


' interarrival   time",  &int_arr_tinie)  =  OPC_COMPCODE_FATLURE)  II 
pa  cket   size",  &packet_size)  =  OPC_COMPCODE_FATLURE)         II 
call  wait   time",&call_wait_time)  =  OPC_COMPCODE_FAILURE)  II 
call   duration",  &call_duration)  =  OPC_COMPCODE_FATLURE)     II 
dest  addr",&dest_addr)  =  OPC_COMPCODE_FAILURE)  II 

QoS  class  \  &qos_class)  =  OPC_COMPCODE_FAILURE)  II 

AAL  type",&AAL_type)  =  OPC_COMPCODE_FAILURE)  II 

(op_ici_attr_get  (req_iciptr,  "peak  cell    rate",  &peak_cell_rate)  =  OPC_COMPCODE_FATLURE)) 
badd_call_sch_error("In  badd_call_sch.call_req:    unable   to  get   values    from  call_req   iciptr" 


opc_nil,  o: 


/*  Destroy  the  ici  to  recover  space,  garbage  collection.  *l 
op_ici_destroy(req_iciptr); 


if  (LTRACE_CALL_SCHEDULER_  ACTIVE) 

{ 

printf("In  badd_call_scheduler  .cal  l_reguest : 

printf("In  badd_call_scheduler.call_request : 

printf("In  badd_call_scheduler.call_request : 

printf("In  badd_call_scheduler.call_request : 

printf("In  badd_call_scheduler.call_request  : 

printf("In  badd_call_scheduler  .call_request : 

printf("In  badd_call_scheduler.call_request : 

printf("In  badd_call_scheduler.call_request : 

printf("  In  badd_call_scheduler  .cal  l_request : 

}  /*  End  if  (LTRACE  CALL  SCHEDULER  ACTIVE)  *l 

I*  Create  and  set  the  fields  in  the  interface  ICI. 

I*  —  Using  local  memory  —  */ 

if_iciptr  =  op_ici_create  ("badd_call_req_if_ici "); 


int_arr_time   =   %f .  \n",  int_aiT_time); 
packet_size   =   %d  .  \n ",  packet_size); 
call_wait_time   =   %f  .  \n",  call_wait_time); 
call_duration  =   %f  .  \n",  call_duration); 
dest_addr   =   %d. \n",  dest_addr); 
qos_class   =   %d.  \n",  qos_class); 
AAL_type  =  % d .  \n  ■ ,  AAL_type); 
peak_cell_rate   =   %f  .  \n",  peak_cell_rate); 
req_iciptr   =   %x.  \n",  req_iciptr); 


*/ 


op_ici_attr_set  (if_iciptr,  "interarrival    time",  int_arr_time); 
op_ici_attr_set  (if_iciptr,  " packet   size",  packet_size); 

call   wait   t  ime " ,  call_wait_time); 

call    duration",  cali_duration); 

dest  addr",  dest_addr); 

QoS  class",  qos_class); 

AAL  type",  AAL_type); 

peak  cell  rate",  peak_cell_rale); 


op_ici_attr_set  (if_iciptr, 
op_ici_attr_set  (if_iciptr, 
op_ici_attr_set  (if_iciptr, 
op_ici_attr_set  (if_iciptr, 
op_ici_attr_set  (if_iciptr, 
op_ici_attr_set  (if_iciptr. 


op_prgJist_insert(calls_pending,  if_iciptr,  OPC_LISTPOS_TATL); 

total_calIs_requested  =  totaJ_calls_requested  +  1; 

/*  Send  an  intrpt  to  start  the  scheduler  if  not  requested.  */ 
sch_requested  =  OPC_COMPCODE_FATLURE; 
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this_event  =  op_ev_current(); 
next_event  =  op_ev_next_local(this_event); 
while  (op_ev_valid(next_event)) 
{ 
if  ((op_ev_type(next_event)  =  OPC_INTRPT_SELF)  && 
(op_ev_code(next_event)  =  BADD_CALL_SCHEDULER)) 

t 
if  (LTRACE_CALL_SCH_  ACTIVE) 

printf(  "Found   scheduler  event,    stopping   search.  \n"); 
sch_requested  =  OPC_COMPCODE_SUCCESS; 
break; 

} 
else 

next_event  =  op_ev_next_local(next_event); 


l*if(schjequested  ==  OPCCOMPCODEFAILURE) 

'*{ 

I*     iffLTRACECALLJCH ACTIVE) 

I*         printfl" Sending  for  scheduler  interrupt \n"); 

I*     opjntrpt_schedule_self(op_simjime  (),  BADD  CALL  SCHEDULER); 

I*}  */ 
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'*  Disable  the  intrpts  to  make  this  process  atomic.  *l 
op_intrpt_disable(OPC_INTRPT_SELF,  BADD_CALL_SCHEDULER.  OPC.FALSE); 

/*  Remove  all  the  other  events  of  this  type  from  the  events  list.  */ 

this_event  =  op_ev_current(); 

next_event  =  op_ev_next_local(this_event); 

while  (op_ev_valid(next_event)) 


if  ((op_ev_type(next_event)  ■■ 
(op_ev_code(next_event)  = 


=  OPC_INTRPT_SELF)  && 
BADD_CALL_SCHEDULER)) 
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if  (LTRACE_CALL_SCH_ACTIVE) 

printf("  Found   next    sch   event,    deleting   event.  \n"); 
scheduler_event  =  next_event; 
next_event  =  op_ev_next_local(scheduler_event); 
op_ev_cancel(scheduler_event); 


else 


next_event  =  op_ev_next_local(next_event); 


/*  Determine  the  number  of  calls  that  must  be  scheduled.  *l 
calls_list_size  =  op_prg_list_size(calls_pending); 

if  (LTRACE_CALL_SCH_ACTIVE) 

{ 

if  (calls_list_size  =  0) 

printf("In   badd_call_scheduler .call    scheduler,    attempted   to  schedule  empty   list."); 
else 

printf("In  badd_call_scheduler  .call    scheduler,    calls    list   size   =   %d .  \n",  calls_list_size); 
} 

/*  Attempt  to  schedule  each  call  in  the  calls j>  ending  list.  */ 
for  (index  =  0;  index  <  calls_list_size;  index++) 

{ 

if  (LTRACE_C  ALL_SCH_ACTIVE) 

{ 

printf("In   badd_call_scheduler.call    scheduler,    index   =   %d .  \n",  index); 

} 

/*  Get  a  call  description  from  the  calls_pending  list.  */ 

call_iciptr  =  (Ici*)  op_prg_Iist_remove(calls_pending,  OPC_LISTPOS_HEAD); 

if  (call_iciptr  =  OPC_NIL) 

badd_call_sch_error( " I n  badd_call_scheduler.call   schedule,    unable   to  get   call_iciptr   from  calls_lis 

if  ((op_ici_attr_get  (call_iciptr,  " peak   cell    rate " ,  &peak_cell_rate)  =  OPC_COMPCODE_FATLURE)) 

badd_call_sch_error("In  badd_sch.call    schedule:    unable   to  get  values   from  call_req   iciptr.  ",  OPC_NII 

if  (LTRACE_CALL_SCH_ACTIVE) 

{ 

printf(-In  badd_call_scheduler.call    schedule:    peak_cel  l_rate   =   %f .  \n",  peak_cell_rate); 
}  /*  End  if(LTRACECALLSCHEDULERACTIVE)  */ 

call_bit_rate  =  peak_cell_rate  *  AMSC_ATM_CELL_SIZE; 

channel_scheduled  =  OPC_COMPCODE_FATLURE; 

least_calls  =  999999; 
least_calls_index  =  -1; 

/*  Find  the  channels  that  can  support  this  call  and  schedule  this  call  on  the  */ 
/*  channel  with  the  least  number  of  calls  currently  scheduled.  *l 

for  (channel_index  =  0;  channel_index  <  sch_channe!_count;  channel_index++) 


{ 


channel_ptr  =  (Badd_Channel_Desc*)  op_prg_list_access(static_channels,  channel_index); 
if  (LTRACE_CALL_SCH_  ACTIVE) 
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printf("In   badd_call_scheduler  .cal  1    scheduler,    ch_capacity   =    %d .  \n",  channel_pti->ch_capacity); 
printf("In   badd_call_scheduler.call    scheduler,    bit    rate   =    %d .  \n",  call_bit_rate); 


/*  Determine  if  this  channel  can  support  the  call  *l 
if  (call_bit_rate  <=  channel_ptr->ch_capacity) 
( 
if  (least_calls_index  <  0) 

least_calls_index  =  channel_index; 

/*  Determine  if  this  channel  has  fewer  calls  than  previous  channels.  *l 
if  (channel_ptr->ch_calls_sch  <  least_calls) 

( 
least_calls_index  =  channel_index; 
least_calls  =  channel_ptr->ch_caUs_sch; 


/*  Found  the  channel  that  can  support  the  call  and  has  the  least  calls  scheduled.  */ 
if  (least_calls_index  >=  0) 
{ 
/*  Remember,  the  list  position  count  is  zero  based.  *l 
if  (LTRACE_CALL_SCH_  ACTIVE) 
{ 
printf("In   badd_call_scheduler  .call    scheduler,    least   calls   index   =   %d.  \n",  least_calis_index); 
printf("In  badd_call_scheduler .call    scheduler,    least   calls   =   %d.  \n",  least_calls); 
) 

/*  Time-stamp  the  request  with  the  current  lime.  */ 
op_ici_attr_set  (call_iciptr,  "time   queued",  op_sim_time()); 

/*  Put  the  call  at  the  tail  of  the  correct  channel  calls _scheduled  list.  *l 
channel_listptr  =  (List*)  op_prg_list_access(calls_scheduled,  least_calls_index); 
op_prgJist_insert(channel_listptr,  call_iciptr,  OPC_LISTPOS_TATL); 

/*  If  this  is  the  first  call  on  the  channel,  start  the  channel.  *l 
if(least_calls<0) 
{ 
if  (LTRACE_CALL_SCH_ACTIVE) 

{ 
printf("In   badd_call_scheduler  .call   scheduler,    calling   start    call    for  channel    %d.  \n",  least_calls_ 
printf("In   badd_call_scheduler  .call   scheduler,    least   calls   =   %d.  \n",  least_calls); 

} 

channe!_iciptr  =  op_ici_create(  "badd_channel_ici  "); 

op_ici_install(channel_iciptr); 

op_ici_attr_set  (channel_iciptr,  "channel    number",  least_calls_index); 

op  intrptscheduleself  (op  am  time  (),  B  ADD_CALL_SCH_START); 
} 

/*  Update  the  calls  scheduled  counter  */ 

least_calls  =  least_calls  +  1; 

channeLptr  =  (Badd_Channel_Desc*)  op_prg_list_access(slatic_channels,  least_calls_index); 

channel_ptr->ch_calls_sch  =  least_calls; 

/*  Update  the  channel  completion  timer.  */ 

if((op_ici_attr_get(call_iciptr,  "call  duration",  &cali_duration)  =  OPC_COMPCODE_FATLURE)  II 
(op_ici_attr_get  (call_iciptr,  "call  wai  t  t  i  me  ■ ,  &call_wait_time)  =  OPC_COMPCODE_FATLURE)) 
badd_call_sch_error( "  I n   badd_sch.call_sch  :    unable   to  get  values    from  call_req   iciptr . ",  OPC_NIL,  OI 
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if  (op_sim_time()  >  channel_ptr->ch_compl_time) 
( 

channel _pir->ch_compl_iime  =  op_sim_iime()  +  call_duraiion  +  call  wait jime  +  channel _delay  *l 
channel_ptr->ch_compl_time  =  op_sim_time()  +  call_duration  +  channel_delay 
+  trans_delay; 
channel  _ptr->ch_compl  jime  =  op_sim_time()  +  call_duration;  */ 
} 

else 
{ 

channel _ptr->ch  compl time  =  channel _ptr->ch  compl  jime  +  call  duration  +  call  wait _time    *! 
channeI_ptr->ch_compl_time  =  channel_ptr->ch_compI_time  +  call_duration 
+  channel_delay  +  trans_delay; 
channel _ptr->ch _com.pl jime  =  channel _ptr->ch _compl jime  +  call  duration;  */ 


if  (LTRACE_C  ALL_TIMER_  ACTIVE) 

printf("In  badd_call_scheduler  .call_schedule:    compl_time   =   %f  .  \r>",  channel_ptr->ch_compl_time) 

/*  Signal  this  call  was  successfully  scheduled.  */ 

if  (LTRACE_C  ALL_SCH_ACTI  VE) 

( 

printf("In  badd_call_scheduler.call    scheduler:    call   scheduled.  \n"); 
) 
channel_scheduled  =  OPC_COMPCODE_SUCCESS; 


if  (channel_scheduled  ==  OPC_COMPCODE_FAILURE) 

! 

printf("Cal  1   parameters   exceeds   the   capacity  of   all    channels .  \n"); 


/*  Turn  the  interrupts  back  on.  *l 
op_intrpt_enable(OPC_INTRPT_SELF,BADD_CALL_SCHEDULER); 
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req_iciptr  =  op_intrpt_ici(); 

if  (req_iciptr  =  OPC_NIL) 

badd_call_sch_error(  "Unable   to  get   call_req   iciptr . ",  OPC_NIL,  OPC_NIL); 


if  ((op_ici_attr  jget  (req. 
(op_ici_attr_get  (req_ 
(op_ici_attr  jget  (req_ 
(op_ici_attrjget  (req_ 
(op_ici_attrjget  (req_ 
(op_ici_attrjget  (req_ 
(op_ici_attr  jget  (req_ 
(op_ici_attrjget  (req_ 
(op_ici_attrjget  (req_ 
badd_call_sch_eiTor( " 


.iciptr,  "interarrival   time",  &int_arr_time)  =  OPC_COMPCODE_FATLURE)  II 

iciptr, -packet   size",  &packet_size)  =  OPC_COMPCODE_FATLURE)         II 

iciptr,  -call   wait   time",  &call_wait_time)  =  OPC_COMPCODE_FAILURE)  II 

iciptr,  -call   du  ra  t  i  on " ,  &call_duration)  =  OPC_COMPCODE_FATLURE)     II 

iciptr,  "dest  addr  \  &dest_addr)  ==  OPC_COMPCODE_FATLURE)  II 

iciptr, -QoS  class-,&qos_cIass)==OPC_COMPCODE_FArLURE)  II 

iciptr,  ■  AAL  type  ■ ,  &AAL_type)  =  OPC_COMPCODE_FAILURE)  II 

iciptr,  -peak  cell    rate",  &peak_cell_rate)  =  OPC_COMPCODE_FAILURE)  II 

iciptr,  "channel   assigned",  &call_release_channel)  =  OPC_COMPCODE_FATLURE)) 

In  badd_call_sch . reschedule :    unable   to   get   values    from  call_req   i c i pt r " ,  OPC_NEL 


op_ici_destroy(req_iciptr); 

if  (LTRACE_C  ALL_RESCHEDULER_ACTrVE) 


printf( 
printf( 
printf( 
printf( 
printf( 
printf( 
printf( 
printf( 
printf( 
}  /*  End 


'In  badd_call_s 
'In  badd_call_s 
'In  badd_call_s 
'In  badd_call_s 
'In  badd_call_s 
'In  badd_call_s 
'In  badd_call_s 
'In  badd_call_s 
'In  badd_call_s 
if(LTRACE_CALL 


cheduler . reschedule 
cheduler . reschedule 
cheduler. reschedule 
cheduler. reschedule 
cheduler. reschedule 
cheduler. reschedule 
cheduler. reschedule 
cheduler .reschedule 
cheduler . reschedule 
SCHEDULER  ACTIVE) 


int_arr_time   =    %f .  \n",  int_arr_time); 
packet_size   =   %d.  \n",packet_size); 
call_wait_time   =  %f .  \n",  cali_wait_time); 
call_duration   =  %f  .\n",  call_duration); 
dest_addr  =   %d  .  \n",  dest_addr); 
qos_class   =   %d .  \n",  qos_dass); 
AAL_type  =   %d  .  \n",  AALjtype); 
peak_cell_rate   =  %t .  \n",  peak_cell_rate); 
req_iciptr   =   %x.  \n",  req_iciptr); 


/*  Reduce  the  channel  completion  time  for  this  call,  it  is  added  back  in  when  the  call  *l 

I*  is  rescheduled.  */ 

channel_ptr  =  (Badd_Channel_Desc*)  op_prg_list_access(static_channeIs,  call_release_channel); 

channel_ptr->ch_compl_time  =  channel_ptr->ch_compl_time  -  call_duration  -  channel_delay  -  trans_delay; 


/*  Create  and  set  the  fields  in  the  interface  1CI. 

ifjciptr  =  op_ici_create(-badd_call_req_if_ici  "); 


*/ 


op_ici_attrjset  (if_iciptr, 
opjicijattrjset  (if_iciptr, 
op_ici_attrjset  (if_iciptr, 
op_ici_attrjset  (if_iciptr, 
op_ici_attr_set  (if_iciptr, 


op_ici_attrjset  (if_ 


"interarrival   t i me " ,  int_arr_time); 
"packet   size",  packet_size); 
"call   wait   t  ime",  call_wait_time); 
"call   duration",  call_duration); 
"dest   addr",  dest_addr); 


op_ici_attr_set  (if_iciptr,  -QoS  class",  qos_class); 


ciptr,  "AAL  type",  AAL_type); 


op_ici_attr_set (if_iciptr,  "peak  cell    rate",  peak_cell_rate); 
op_prgJistJnsert(calls_pending,  if_iciptr,  OPC_LISTPOS_HEAD); 


l*if(sch_requested  ==  OPCCOMPCODE  FAILURE) 

I*      op  _intrpt  schedule  self (op  jimjime  ().  BADDCALL  SCHEDULER); 

I*     *l 
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transition    reschedule 

->  dispatch 

attribute 

value 

tvpe 

default  value 

name 

tr  149 

string 

tr 

condition 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

spline 

toggle 

spline 

forced  state   check  channel 


attribute 


value 


type 


default  value 


name 

enter  execs 
exit  execs 
status 


check  channel 
(See  below.) 
(empty) 
forced 


string 
textlist 
textlist 
toggle 


st 

(empty) 
unforced 


enter  execs    check  channel 


10 


15 


20 


25 


/*  Gel  the  lei  passed  from  the  call  generator  and  determine  what  channel  must       */ 
I*  be  checked  for  additional  calls.  If  the  channel  has  additional  calls  waiting,  */ 
/*  then  send  an  interrupt  to  start  the  next  call.  */ 

check_channel_iciptr  =  op_intrpt_ici(); 

if  (op_ici_attrj;et  (check_channel_iciptr,  "channel   number",  &check_chan_index)  =  OPC_COMPCODE_FAILURE) 
badd_call_sch_error( "Unable  to   read  check  channel   iciptr . ",  OPC_NIL,  OPC_NIL); 

op_ici_destroy(check_channel_iciptr); 

if  (LTRACE_CALL_SCH_ACTIVE) 

printf("In  badd_call_scheduler  .call    scheduler  .check_channel :    channel    =   %d.  \n",  check_chan_index); 

channel_ptr  =  (Badd_Channel_Desc*)  op_prg_list_access(static_channeIs,  check_chan_index); 

/*  Check  the  channel  for  additional  calls  waiting  and  start  the  next  call  if  available.  *l 

if  (channel_ptr->ch_calls_sch  >=  0) 

( 

channel_iciptr  =  op_ici_create(  "badd_channel_ici  "); 

op_ici_install(channel_iciptr); 

op_ici_attr_set  (channel_iciptr,  "channel    number" ,  check_chan_index); 

opintrptscheduleself  (opsimtime  ()  +  channel_delay,  BADD_CALL_SCH_START); 


if  (LTRACE_CALL_TIMER_  ACTIVE) 

printf("In  badd_call_sch. check  channel:    current    time   =   %l .  \n",  op_sim_time()); 


transition    check  channel  ->  dispatch 


attribute 
name 


value 
tr  152 


type 
string 


default  value 
tr 
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condition 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

spline 

toggle 

spline 
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APPENDIX  F. 
BADD_CALL_SCHEDULER_GREEDY. 
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External  File  Set 


attribute 


value 


type 


default  value 


external  file  set 


badd  functions 


typed  file 


Process  Model  Comments 


General  Process  Description: 


The  badd_call_scheduler  schedules  and  manages  all  static  channel 
assignments  for  the  BADD  network.  This  model  schedules  calls  by  assigning 
new  calls  to  the  channel  based  on  a  greedy  min-min  algorithm. 

ICI  Interfaces: 


badd_call_req_if_ici 
badd_call_gen_if_ici 

Packet  Formats: 

None. 

Statistic  Interfaces: 

None 

Process  Registry: 

Published  Attributes  and  Expected  Attributes:  None 

Restrictions: 

None 


Process  Model  Attributes 

Attribute  dest  addr  properties 

Property 

Value 

Default  Value: 

NONE 

Data  Type: 

integer 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Specifies  the  destination  of 

the  call. 

Symbol  Map: 

Symbol                                     Value 

NONE                                       -1 

Allow  other  values: 

YES 

Attribute  scheduler  delay  properties 

Property 

Value 

Default  Value: 

0.0 
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Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Units: 

seconds 

Comments: 

The  maximum  time  in  seconds 

between  scheduler  events. 

Attribute  transmission  delay  properties 

Property 

Value 

Default  Value: 

0.25 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Units: 

seconds 

Attribute  channel  delay  properties 

Property 

Value 

Default  Value: 

7.681  E-05 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Units: 

seconds 

Comments: 

The  delay  between  calls  on 

the  same  channel. 

Attribute  calls  pending  properties 

Property 

Value 

Default  Value: 

0 

Data  Type: 

integer 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

The  maximum  number  of  calls 

to  store  in  the 

calls_pending  list  before 

running  a  schedule  process. 

Process  Model  Interface  Attributes 

Attribute  begsim  intrpt  properties 

Property 

Value                                                                   Inherit 

Assign  Status: 

hidden 

Initial  Value: 

enabled                                                                  N/A 

Default  Value: 

disabled                                                                 YES 

Data  Type: 

toggle                                                                     N/A 

Attribute  Description: 

Private                                                                    N/A 

Comments: 

YES 

This  attribute  specifies  whether  a  'begin  simulation 

interrupt'  is  generated  for  a  processor  module's  root 

process  at  the  start  of  the  simulation. 
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Symbol  Map: 

NONE 

YES 

Attribute  endsim  intrpt  properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

enabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  an  'enc 

simulation 

interrupt'  is  generated  for  a  processor 

module's  root 

process  at  the  end  of  the  simulation. 

Symbol  Map: 

NONE 

YES 

Attribute  failure  intrpts 

properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

enumerated 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  failure  interrupts 

are  generated  for  a  processor  module's  root  process 

upon  failure  of  nodes  or  links  in  the  network  model. 

Symbol  Map: 

NONE 

YES 

Attribute  intrpt  interval 

properties 

Property 

Value 

inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle  double 

N/A 

Attribute  Description: 

Private 

N/A 

Units: 

sec. 

YES 

Comments: 

YES 

This  attribute  specifies  how  often  regul 

ar  interrupts 

are  scheduled  for  the  root  process  of  a 

processor  module. 

Symbol  Map: 

NONE 

YES 

Attribute  priority  properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

0 

N/A 

Default  Value: 

0 

YES 

Data  Type: 

integer 

N/A 

Attribute  Description: 

Private 

N/A 

Low  Range: 

-32767  inclusive 

YES 

High  Range: 

32767  inclusive 

YES 
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... 

Comments: 

YES 

This  attribute  is 

used  to  determine  the  execution  order 

of  events  that  are  scheduled  to 

occur  at  the  same 

simulation  time. 

Symbol  Map: 

NONE 

YES 

Attribute  recovery  intrpts 

properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

enumerated 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  recovery  interrupts 

are  scheduled  for  the  processor 

module's  root  process 

upon  recovery  of  nodes  or  links 

in  the  network  model. 

Symbol  Map: 

NONE 

YES 

Attribute  super  priority  properties 

Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  is 

used  to  determine  the  execution  order 

of  events  that  are  scheduled  to 

occur  at  the  same 

simulation  time. 

Symbol  Map: 

NONE 

YES 

Process  Model  Simulation  Attributes 

Attribute  class  A  CDV 

tolerance 

properties 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 
variance  that  two 
consecutive  Quality  of 
Service  (QoS)  class  A  cells 
may  experience. 

Attribute  class  B  CDV 

tolerance 

properties 

Property 

Value 

Default  Value: 

0.0 
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Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 

variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  B  cells 

may  experience. 

Attribute  class  C  CDV  tolerance 

properties 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 

variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  C  cells 

may  experience. 

Attribute  class  D  CDV  tolerance 

properties 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 

variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  D  cells 

may  experience. 

Header  Block 

#include  ■  /usr71ocal/mil3_dir 
#include  " /usr/local/mil3_dir 
frinclude  " /usr/work/benton/op 

/3 . 0 .A_DL5 /models /st d/atm/ams_interf aces. h" 

/3 .0 . A_DL5 /models/ st d/atm/ams_aal_inter faces .h" 

_code/badd_interf ace .h" 

5 

1*  These  are  transition  conditions.  *l 
#defme  SIGNAL 

((op  intrpt  type  ()  =  OPC_INTRPT_REMOTE)  &&       \ 
(op_intrpt_code  ()  =  AMSC_INTERFACE_SIGNAL)) 

10 

#define  CALL_REQ_SIGNAL 

((op_intrpt_type  ()  =  OPC_INTRPT_REMOTE)  &&       \ 
(opmtrptcode  ()  =  BADD_REQUEST_SIGNAL)) 

15 

#defme  AAL_CALL_SETUP 

((SIGNAL)  &&                                                                    \ 
((primitive  ==  AMSC_AAL_ESTAB_Req)  II                       \ 
(primitive  =  AMSC_AA_ESTAB_Ind))) 

#defme  SAAL_S1GNAL 

((op  intrpt  type  ()  =  OPC_INTRPT_REMOTE)  &&       \ 
(op  intrpt  code  ()  =  AMSC_SAAL_SIGNAL)) 
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20 


25 


30 


35 


40 


45 


50 


55 


60 


65 


70 


75 


#defme  AAL_DATA 
#defme  EST_CON 
#defme  REL_IND 
#define  REL_CON 
#define  CALL_START 

#define  CALL_END 

#defme  SCHEDULER 

#define  RESCHEDULE 


(opintrptjype  ()  =  OPC_INTRPT_STRM) 

(SIGNAL  &&  (primitive  =  AMSC_AAL_ESTAB_Con)) 

(SIGNAL  &&  (primitive  =  AMSC_AAL_RELEASE_Ind)) 

(SIGNAL  &&  (primitive  =  AMSC_AAL_RELEASE_Con)) 

((op_intrpt_type  ()  ==  OPC_INTRPT_SELF)  &&  \ 

(op_intrpt_code  ()  =  BADD_CALL_SCH_START)) 

((opjntrpt  type  ()  =  OPC_INTRPT_SELF)  &&  \ 

(opintrptcode  ()  =  AMSC_TGEN_CALL_END)) 

((opjntrpt  type  ()  =  OPC_INTRPT_SELF)  &&  \ 

(op_intrpt_code  ()  ==  BADD_CALL_SCHEDULER)) 

((opjntrpt  type  ()  =  OPC_INTRPT_REMOTE)  &&       \ 
(op_intrpt_code  ()  =  BADD_CALL_RESCHEDULE)) 


#defme  CHECK_CHANNEL_SIGNAL        ((opjntrpttype  ()  ==  OPC_INTRPT_REMOTE)  &&       \ 

(op_intrpt_code  ()  =  BADD_CHECK_CHANNEL)) 

#defme  WAIT_CALL_DURATION      ((opjntrpttype  ()  =  OPC_INTRPT_SELF)  &&  \ 

(op jntrpt  code  ()  =  AMSC_TGEN_WAIT_CALL_DURATION)) 


#defme  ENDJSIMULATION 
#define  NEIGHBOR_NOTIFY 

#define  NOTIFYCOMPLETE 


((opjntrpt  type  ()  =  OPC_INTRPT_ENDSIM)) 

((opjntrpt  type  ()  =  OPC_INTRPT_REMOTE)  &&       \ 
(op_intrptj:ode  ()  =  AMSC_NEIGHBOR_NOTIFY)) 

(ams_neighbor_notify_is_complete  (nbr_dala_ptr)  =  OPC_TRUE) 


/*  These  are  self  interrupt  codes.  */ 

#define    BADD_CALL_SCH_START  0 

#define  AMSC_TGEN_CALL_END  1 

#define  AMSC_TGEN_DATAj3EN  2 
#define  AMSC_TGEN_WAIT_CALL_DURATION    3 

#define  BADD_CALL_SCHEDULER  4 

#define  BADD_CALL_RESCHEDULE  5 

#defineBADD  CHECK  CHANNEL  6 


/*  These  are  constants  */ 
#define  MAX_CHANNELS 
#define  MAXSIZE 
#define  MAX  COMPL  TIME 


1024 

11 

9999999.9 


/*  The  scheduler  process  will  output  trace  information  if  these  conditional  are  true.  */ 

#define  LTRACE_ ACTIVE  (debug_mode  && 

(op_prg_odb_ltracejictive  ("ams ")  II 
op_prg_odbJ"trace_active  ( "  ams_t  ra  f " )  II 
op_prg_odbj"trace_active  ( °ams_t  raf_gen "))) 


#define  LTRACEjCONNECT_ACTIVE  (op  j^rgodb  Itraceactive  ( "connect  ■)) 

#denneLTRACEjCALL_SCHEDULER_ACTrv'E     (opj^rg_odb_ltracejictive  ("call_scheduler")) 
#define  LTRACE_CALL_SCH_ACTIVE  (op  prgodbltrace  active  ('•  ca  1  l_sch  ■ )) 


233 


Process  Model  Report:  baddcallschedulergreedy 

TueJun  17  10:52:08  1997 

Page  7  of  38 

so 


85 


90 


#deHne  LTRACE_CALL_DISP_ACTIVE  (op_prg_odb_ltrace_active  ("cal  l_disp")) 

#define  LTRACE_CALL_CHANNELS_  ACTIVE       (opprgodbjtraceactive  ("cal  l_channels")) 

#define  LTRACE_CALL_TIMER_ ACTIVE        (opprgodb  Jtraceactive  ("cal  l_timer-)) 

#dermeLTRACE_CALL_GREEDY_ACTIVE    (opprgodbjtraceactive  ("cal  l_g  reedy")) 

#define  LTRACE_CALL_RESCHEDULER_ ACTIVE        (op_prg_odb_ltrace_active  ( ■  c a  1  l_res chedu  1  e r " )) 

/*  Function  declarations.  *l 

void  badd_call_sch_nbr_intrpt_proc  (); 

void  badd_call_sch_spurious_signaI_handle  (); 

void  badd_call_sch_list_print  (); 

void  badd_call_sch_matrix_print  (); 

void  badd_call_sch_error  (); 


State  Variable  Block 

int                                 \debug_mode; 

int                                   \packet_size; 

int                                   \dest_addr; 

int                                 \AAL_type; 

5 

int                                   \qos_class; 

int                                   \to_aal_stream_index; 

int                                   \to_req_stream_index; 

int                                   \sch_channel_count; 

int                                   \number_calls_pending; 

10 

int                                   \max_calls_pending; 

double                            \avg_rate; 

double                            \channel_delay; 

double                            \trans_delay; 

double                            M:ime_to_next_scheduler, 

15 

double                            \end_sim_time; 

char                                Npid_string  [128]; 

Objid                              \my_id; 

Objid                              \aal_module_id; 

Objid                                Veq_module_id; 

20 

List*                               \calls_pending; 

List*                               \calls_scheduled; 

List*                               \static_channels; 

FILE*                             \output_file; 

FILE*                             \output_caIls; 

25 

Ici*                                 \aal_handle_iciptr; 

Evhandle                        \next_packet_arrival; 

Evhandle                        \call_end_intrpt; 

Distribution*                   \int_arrival_distptr; 

Distribution*                  \call_wait_distptr; 

30 

Distribution*                  \call_duration_distptr. 

AmsT_Traf_Contract*    Mraf_con_ptr; 

AmsT_Neighbor_Data*  \nbr_data_ptr; 

Badd_Sch_Mod_Data    \Scheduler_Module; 

Badd_Channel_Desc*    \channel_ptr; 

35 
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Temporary  Variable  Block 

int                                   primitive; 

int                                   cd_packet_size; 

int                                   clark_dest_addr, 

int                                      calls_list_size; 

5 

int                                    index  =  0; 

int                                    channel_index; 

int                                    sch_channel_index; 

int                                   check_chan_index; 

int                                   call_bit_rate; 

10 

int                                   call_compl_channel; 

int                                   call_release_channel; 

int                                   total_channels  =  0; 

int                                  channel_count  =  0; 

int                                   value; 

15 

int                                    least_channel_index; 

int                                   least_call_index; 

int                                   temp_intrpt_type; 

int                                   temp_intrpt_code; 

int                                    remain_to_schedule; 

20 

int                                  row_index; 

int                                    col_index; 

int*                                 int_ptr; 

int*                                 channel_size_ptr; 

double                            peak_cell_rate; 

25 

double                             cdv_tolerance; 

double                           int_arr_time; 

double                             call_wait_time; 

double                             call_duration; 

double                             event_time; 

30 

double                             least_compl_time; 

double                             channel_compl_time; 

double                            temp_double; 

double              temp_PCR; 

double                              time_enqueued; 

35 

double                            time_dequeued; 

double                            time_in_queue; 

double*                           compl_time_ptr, 

extern  int                        total_calls_requested; 

extern  int                        total_calIs_generated; 

40 

extern  int                        total_calls_received; 

extern  int                        total_cal!s_active; 

extern  int                        max_calls_active; 

char                                string[ll]; 

Ici*                                 if_iciptr; 

45 

Ici*                                 req_iciptr. 

Ici*                                 call_iciptr; 

Ici*                                 signal_iciptr; 

Ici*                                 setup_iciptr; 

Ici*                                 upper_handle_iciptr; 

50 

Ici*                                 check_channel_iciptr; 

Ici*                                 channel_iciptr; 

Ici*                                 sch_channel_iciptr; 

Prohandle                        call_gen_prohandle; 

Prohandle*                      call_gen_proptr; 

55 

Evhandle                         this_event; 

Evhandle                         next_event; 

Evhandle                         scheduler_event; 
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List*                                channel_listptr; 

List*                                sch_channel_listptr; 

60 

List*                                temp_calls_sch_list; 

List*                                row_listptr. 

FILE*                                input_file; 

Compcode                       channel_scheduled; 

Compcode                       sch_requested; 

65 

AmsT_Traf_Contract*    tmp_traf_con_ptr; 

Function  Block 

void 

badd_calI_sch_nbr_intrpt_proc  (ndata_ptr,  ndesc_ptr,  slate_ptr) 

AmsT_Neighbor_Data*  ndata_ptr; 

AmsT_Neighbor_Desc*  ndesc_ptr; 

5 

void*                               state_ptr; 

{ 

AmsT_Neighbor_Verify_Desc       vdesc; 

int                                                   to_sw_stream_index; 

10 

/**  This  procedure  handles  a  neighbor  notification  event  in  an  AMS 

**/ 

/**  traf  gen  specific  manner.  It  determines  the  neighbor' s  object 

**/ 

/**  ID  and  type,  and  verifies  that  there  are  a  correct  number  of 

**/ 

/**  interconnections. 

**/ 

15 

FIN  (badd_call_sch_nbr_intipt_proc  (ndata_ptr,  ndesc_ptr.  state_ptr)); 

/*  Switch  based  on  the  AMS  type. 

*/ 

switch  (ndesc_ptr->module_amstype) 

t 

case  AMSC_MTYPE_AAL: 

20 

{ 

/*  Build  the  verify  desc  data  structure. 

*/ 

vdesc.modjd                  =  my_id; 

vdesc.nbr_id                   =  ndesc_ptr->module_objid; 

vdesc.nbr_id_ptr             =  &aal_module_id; 

25 

vdesc.mod_name             =  "BADD  Call    Scheduler"; 
vdesc.nbr_name              =  "AM,"; 
vdesc.nbr_type               =  AMSC_MTYPE_AAL; 
vdesc.from_nbr_strm_cnt                      =  1; 
vdesc.from_nbr_strm_index_ptr             =  OPC_NIL; 

30 

vdesc.to_nbr_strm_cnt                           =  1; 
vdesc.to_nbr_strm_index_ptr                 =  &to_aal_stream_index; 

/*  Verify  that  the  neighbor  has  the  correct 

*/ 

1*  characteristics. 

*/ 

35 

ams_neighbor_verify  (&vdesc); 

break; 

) 

40 

case  BADD_MTYPE_SCHEDULER_CLIENT: 

t 

/*  Build  the  verify  desc  data  structure. 

*/ 

vdesc.mod_id                  =  my_id; 

vdesc.nbr_id                   =  ndesc_ptr->module_objid; 

45 

vdesc.nbr_id_ptr             =  &req_module_id; 
vdesc.mod_name             =  "BADD   Call    Scheduler"; 
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vdesc.nbr_name  =  "call_req"; 

vdesc.nbrjype  =  BADD_MTYPE_SCHEDULER_CLIENT; 

vdesc.from_nbr_strm_cnt  =  1; 

vdesc.from_nbr_strm_index_ptr  =  OPC_NEL; 

vdesc.to_nbr_strm_cnt  =  1; 

vdesc.to_nbr_strm_index_ptr  =  &to_req_stream_index; 

/*  Verify  that  the  neighbor  has  the  correct 

I*  characteristics. 

I*  ams_neighbor_verify  (&vdesc);  *l 

break; 


default 


/*  This  is  an  unexpected  neighbor  notification.  */ 

/*  Issue  error  message.  */ 

op_sim_end  ("Process    received   a   neighbor  notification    from  a   module", 

"of   an   unexpected   type.      Simulation  terminated  .",  OPC_NIL,  OPC_NIL); 

break; 

) 


FOUT; 
) 

void 
badd_call_sch_spurious_signal_handle  () 


Ici* 

Ici* 

int 

Ici* 

Packet* 


if_iciptr; 

release_if_iciptr; 

primitive; 

ll_handle_iciptr, 

pkptr, 


/*  This  procedure  handles  spurious  interrupts. 

I*  Only  three  types  of  spurious  interrupts  can  be  accepted.  All 

I*  others  must  result  in  an  op_sim_end  ().  These  three 

I*  interrupts  are: 

/*      1.  An  AAL  ESTAB  lnd. 

/*     2.  An  AAL  RELEASE  Con. 

/*      3.  A  packet  arrival. 

FIN  (badd_call_sch_spurious_signal_handle  ()); 

if  ( AAL_CALL_SETUP) 

{ 

/*  This  is  a  signal  from  the  AAL. 

I*  Obtain  the  ICI  pointer. 
if_iciptr  =  op_intrpt_ici  (); 

/*  Obtain  the  primitive  from  the  ICI. 

op_ici_attr_get  (ifjciptr,  "pr  imit  ive ",  &primitive); 

/*  Obtain  the  'lower  layer  handle'  from  the  ICI. 

op_ici_attr_get  (ifjciptr,  "lower   layer  handle",  &ll_handle_iciptr); 
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/*  Switch  on  the  'primitive' .  *l 

switch  (primitive) 

{ 

case  AMSC_AAL_ESTAB_Ind: 

( 

/*  This  is  an  'establish  indication'  from  the  AAL.  */ 

if(LTRACE_ACTIVE) 

( 

op_prg_odb_print_major  (pid_string,  "Received   spurious  AAL   ESTABLISH   Request    signal. 
"Call    not    accepted.  ",  "Sending   AAL   RELEASE  Request    signal  .",  OPC_NIL); 


/*  Set  the  'upper  layer  handle'  in  the  interface  *l 

I*  1C1  for  the  'establish  indication  signal,  since  *l 

I*  the  lower  layer  expects  it  to  be  filled  in.  The  *l 

I*  ICI  is  not  destroyed,  since  this  is  a  forced  */ 

/*  interrupt  and  the  lower  layer  process  expects  */ 

/*  to  obtain  the  handle  from  the  ICI  when  the  */ 

/*  control  returns.  *l 
op_ici_attr_set  (if _iciptr,  "upper   layer  handle",  OPC_NIL); 

/*  Simply  send  an  AAL_RELEASE_Req  to  request  that  *l 

I*  the  connection  be  released.  */ 

release_if_iciptr  =  opicicreate  (AMSCJNTERFACEJCI); 
op_ici_attr_set  (release_if_iciptr,  "primitive",  AMSC_AAL_RELEASE_Req); 
op_ici_attr_set  (release_if_iciptr,  "lower   layer  handle",  ll_handle_iciptr); 
op_ici_install  (release_if_iciptr); 

/*  Send  a  remote  interrupt  which  will  carry  the  ICI  to  the  AAL  module.  *l 
opintrptscheduleremote  (opsimtime  (),  AMSC_INTERFACE_SIGNAL,  aal_modu!e_id); 

break; 


case  AMSC_AAL_RELEASE_Con: 
{ 
/*  This  is  a  '  release  confirm'  from  the  AAL.  */ 

if(LTRACE_ACTIVE) 

( 

op_prg_odb_print_major  (pid_string,  "Received  spurious  AAL   RELEASE  Confirm  signal." 
"This    in   response    to   AAL   RELEASE   Request    terminating    spurious   connection. 


} 


OPC_NIL); 


/*  This  is  a  response  to  our  earlier  'release 
I*  request'  which  was  a  response  to  the 
I*  spurious  '  estab  indication  . 
/*  Do  nothing  other  than  destroy  the  ICI. 
op_ici_destroy  (if_iciptr); 

break; 

} 

default: 

f 

/*  This  is  some  other  completely  unexpected 

I*  signal.  Issue  error  message  and  terminate 
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/*  simulation.  *l 

op_sim_end  ("In  badd_call_scheduler,    Received   unexpected   signal. 


••"): 


else  if  (opjntrpttype  ()  =  OPC_INTRPT_STRM) 

{ 

/*  This  is  a  spurious  packet  arrival.  The  ams_traf_gen 

I*  just  destroys  this  packet. 

if(LTRACE_ACTIVE) 


*/ 

*/ 


op_prg_odb_print_major  (pid_string,  "Received   spurious   DATA  packet. 
"Destroying  the  packet .",  OPC_NIL); 


/*  Get  the  packet  fromt  the  stream  and  destroy  it. 
pkptr  =  op_pk_get  (op_intrpt_strm  ()); 
op_pk_destroy  (pkptr); 


*l 


else 


/*  This  is  some  other  completely  unexpected 

I*  interrupt.  Issue  error  message  and  terminate 

I*  simulation. 

op_sim_end  ("Received  unexpected  interrupt. 


*/ 
*/ 
*/ 


FOUT; 


void 

badd_ca]l_sch_list_print  (callsjist) 

List*        callsjist; 

( 

int    list_size; 

int     index  =  0; 

int    list_packet_size; 

int    list_dest_addr; 

int     list_qos_class; 

int     list_AAL_type; 

double  list_bit_rate; 

double  list_int_arr_time; 

double  list_call_wait_time; 

double  list_call_duration; 

double  list_peak_cell_rate; 

Ici*    req_iciptr; 


/*  This  procedure  will  print  all  the  calls_descs  in  the  calls _pending  list  *l 
FIN  (badd_call_schjist_print(cal)sjist)); 

list_size  =  op_prg_list_size(calls_list); 


if  (list_size  =  0) 


printf(' 


Attempting   to  print    empty   call_list .  \n"); 


for  (index  =  0;  index  <  list_size;  index++) 
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req_iciptr  =  (Ici*)  op_prg_list_access  (callsjist,  index); 

if  (reqjciptr  =  OPC_NIL) 

badd_caJI_sch_error(  "Unable   to   get    req_iciptr   from  calls_pending   1  ist .  ",  OPC_NIL,  OPC_NIL); 

if  ((op  ici_attr_get  (reqjciptr,  ■  interarrival    t ime " ,  &list_int_arr_time)  ==  OPC_COMPCODE_FAILURE)  II 
(op_ici_attr_get  (reqjciptr,  "packet   size",  &list_packet_size)  =  OPC.COMPCODEJFATLURE)        II 
(op jci_attr_get  (reqjciptr,  "call  wait  time",  &list_call_wait_time)  ==  OPC.COMPCODEJ^ATLURE)  II 
(op_ici_attr_get  (reqjciptr,  "call   durat ion ",  &list_call_duration)  ==  OPC_COMPCODEJ^ATLURE)     II 
(op Jci_attr_get  (reqjciptr,  " dest   addr " ,  &list_dest_addr)  =  OPC_COMPCODEJ^AILURE)  II 

(opJcfattr_get  (reqjciptr,  "QoS  class",  &list_qos_class)  =  OPC_COMPCODEJ^ATLURE)  II 

(op_ici_attr_get  (reqjciptr,  "AAL  ty pe " ,  &list_AAL_type)  =  OPC_COMPCODEJ^AILURE)  II 

(opjciattrjget  (reqjciptr,  "peak  cell    rate",  &list_peak_celi_rate)  ==  OPC_COMPCODEJ=ATLURE)) 
badd_call_sch_error( "Unable   to   get   values    from  call_req   iciptr",  OPCJ^JIL,  OPC_NIL); 

printf("In   badd_call_scheduler  .print  ing   cal  ls_pending    list:    int_arr_time   =   %f.\n", 

listjnt_arr_time); 
printf("In   badd_call_scheduler  .printing   cal  ls_pending    list:    packet_size    =   %d.\n", 

list_packet_size); 
printf("In  badd_call_scheduler. printing  calls_pending    list:    call_wait_time   =   %f.\n", 

list_call_wait_time); 
printf("In  badd_call_scheduler .printing  calls_pending   list:    call_duration   =   %f.\n", 

list_call_duration); 
printf("In  badd_call_scheduler  .printing  cal  ls_pending    list:    dest_addr  =   %d.\n", 

list_dest_addr); 
printf("In   badd_call_scheduler  .print  ing  cal  ls_pending    list:    qos_class   =   %d.\n", 

list_qos_cIass); 
printf("In  badd_call_scheduler  .printing  cal  ls_pending   list:    AAL_type   =   %d.\n", 

list_AAL_type); 
printf("In   badd_call_scheduler.  printing  cal  ls_pending    list:    peak_cel  l_rate   =   %f.\n", 

list_peak_cell_rate); 
printf("In   badd_call_scheduler  .printing  cal  ls_pending    list:    bit_rate   =  %f.\n", 

list_peak_cell_rate  *  424); 
}  /*  End  for  loop  *l 

FOUT; 


void 

badd_call_sch_matrix_print  (sch_matrix) 

List*        sch_matrix; 

{ 

int     number_of_rows; 

int     number_of_cols; 

int      list_rowJndex; 

int      list_colJndex; 

List*    matrix_row_ptr, 

double*  list_compI_time; 


/*  This  procedure  will  print  all  the  elements  in  the  call  scheduling  matrix  */ 
FIN(badd_call_sch_matrix_print(sch_matrix)); 

number_of_rows  =  op_prg_list_size(sch_matrix); 

if  (number_of_rows  =  0) 

{ 


printf(' 


Attempting  to  print  empty  sch_matrix.  \n"); 
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for  (list_row_index  =  0;  list_row_index  <  number_of_rows;  list_row_index++) 
{ 
matrix_row_ptr  =  (List*)  op_prg_Iist_access  (schjmatrix,  list_row_index); 

if  (matrix_row_ptr  =  OPC_NIL) 

badd_call_sch_error( "Unable   to   get    row    from  sch_matrix.  ",  OPC_NBL,  OPC_NIL); 

number_of_cols  =  op_prg_list_size(matrix_row_ptr); 

if  (number_of_cols  =  0) 


{ 


printf(" 


Attempting  to  print  empty  row  from  sch_matrix.  \n"); 


for  (list_col_index  =  0;  list_col_index  <  number_of_cols;  list_coI_index++) 

{ 

list_compl_time  =  (double*)  op_prg_list_access  (matrix_row_ptr,  list_col_ifidex); 

printf("In   badd_call_scheduler. printing   sch_matrix   elements:    row   %d,    col    %d,    compl_time   %f.\n" 
list_row_index,  list_col_index,  *list_compl_time); 
)  /*  End  for  (list  _col  jndex  =  0;  list col jndex  <  number _of  cols;  list_coljndex++)  *l 

)  I*  End  for  (list _row  index  =  0;  list  row  jndex  <  number _of_rows;  list_row_index++)  *l 

FOUT; 

} 

void 

badd_call_sch_eiTor  (msgO,  msgl,  msg2) 

char*  msgO; 

char*  msgl; 

char*  msg2; 

f 

/**  Print  an  error  message  and  exit  the  simulation.  **/ 

FIN  (badd_call_sch_error  (msgO,  msgl,  msg2)); 

op_sim_end  ("Error   in   badd_call_scheduler  process:", 
msgO,  msgl,  msg2); 

FOUT; 


Diagnostic  Block 


/*  Display  connection  information,  if  requested.  *l 
if  (LTRACE_CONNECT_ACTrVE) 

I 

/*  Print  information.  *l 

ams_neighbor_data_print  (nbr_data_ptr,  ams_neighbor_desc_print_noop); 
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forced  state    INIT 

attribute 

value 

tvpe 

default  value 

name 

enter  execs 
exit  execs 
status 

INIT 

(See  below.) 

(empty) 

forced 

string 
textlist 
textlist 
toggle 

st 

(empty) 
unforced 

enter  execs    INIT 

/*  Determine  the  initial  values  of  the  slate  variables  and  set  up 
1*  the  initial  state  of  this  instantiation  of  the  ams  traf  gen 
1*  process. 

*/ 
*/ 
*/ 

5 

1*  Obtain  the  object  ID  of  this  process'  parent  module. 
my_id  =  op_id_self  (); 

*/ 

10 

/*  Determine  whether  or  not  the  simulation  is  in  debug  mode. 
debug_mode  =  op_sim_debug  (); 

*/ 

/*  Initialize  the  AAL  module  object  ID  to  NULL  value. 
aal_module_id  =  OPC_OBJID_NULL; 
req_module_id  =  OPC_OBJID_NULL; 

*/ 

15 

/*  Create  a  list  for  storing  the  calls  as  they  arrive  */ 
calls_pending  =  op_prg_list_create(); 

20 

/*  Read  the  static  channels  input  file  and  create  lists  accordingly.  *l 
static_channels  =  op_prg_Iist_create(); 
calls_scheduled  =  op_prg_list_create(); 

25 

/*  Open  the  channel  definition  file.  *l 

if  ((input_file  =  fopen("/usr/work/benton/input_channels  ",  "r")) 

=  NULL) 

( 

badd_call_sch_error( " Problem  opening  static   channel    definition   f 
OPC.NLL,  OPC_NIL); 

Lie.", 

30 

) 

if  (fgets  (  string,  MAXSIZE,  input_file  )  !=  NULL) 

r 

1 
if  (LTRACE_CALL_CHANNELS_ACTrVE) 

printf("In   badd_call_sch.  init ;    string    is   %s  .  \n",  string); 
if  (get_digit( string,  &value)  =  OPC_COMPCODE_F ALLURE) 

35 

badd_calI_sch_eiTor  ("Invalid  number  of   static   channels.", 
OPC_NIL,  OPC_NIL); 
1 

40 

1 

total_channels  =  value; 

if  (LTRACE_C  ALL_CHANNELS_ACTrVE) 

{ 
printf("In  badd_call_sch.  load_static_channels    function  after 
printf("    count  ;total_channels   =   %d .  \n",  total_channels); 

) 

reading   channel 

"): 

45 

} 

if  (total_channels  >  MAX_CHANNELS) 

1 

badd_call_sch_error( "Requested  virtual    channels   exceeds   maximum 

al  lowed .  ", 
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OPC_NDU  OPC_NIL); 


while  ((fgets  (  string,  MAXSIZE,  input_file  )  !=  NULL)  && 
(channel_count  <  total_channeIs)) 

{ 
if  (LTRACE.C  ALL_CHANNELS_  ACTIVE) 

{ 

printf("In  badd_call_sch. init ,    reading  each  channel   size,-"); 

prinrf("   channel_count    =   %d.  \n",  channel_count); 

printf("In   badd_call_sch.  init ;    string  value   is   %s  .  \n",  string); 
) 

if  (get_digit( string,  &value)  =  OPC_COMPCODE_FAILURE) 
{ 

badd_call_sch_error  ("Invalid  number  for  static  channels.", 
OPC.NIL,  OPC_NIL); 
} 
if  (value  >  8000000) 

{ 
badd_call_sch_error  ( 

} 

channel_ptr  =  (Badd_Channel_Desc*)  op_prg_mem_alloc(sizeof(Badd_Channel_Desc)); 
if  (channel_ptr  =  OPC_NIL) 
( 
badd_call_sch_error( "Unable   to   allocate  memory   for  channel   definition.", 
OPC.NIL,  OPC_NIL); 
} 

channel_pf->ch_capacity  =  value; 
channel_ptr->ch_calls_sch  =  -1; 
channel_ptr->ch_calls_compl  =  0; 
channel_ptr->ch_compl_time  =  0.0; 

op_prg_list_insert(static_channels,  channel_ptr,  OPC_LISTPOS_TATL); 
if  (LTRACE_C  ALL_CHANNELS_  ACTIVE) 

{ 
printf("In   badd_call_sch.  init ,    channel   value  saved   =   %d.  \n",  channel_ptr->ch_capacity); 


/*  Create  a  list  to  store  the  calls  for  this  channel  */ 
channel_listptr  =  op_prg_list_create(); 
if  (channeljistptr  =  OPC_NIL) 
{ 
badd_call_sch_error( "Unable   to   allocate  memory   for  channel    list. 
OPC_NEL,  OPC_NIL); 
) 

op_prgJist_insert(calls_scheduled,  channel_listptr,  OPC_LISTPOS_TATL); 
channel_count  =  channel_count  +  1; 

) 

if  (LTRACE_C  ALL_CHANNELS_ACTrVE) 

{ 
channeI_count  =  op_prg_Iist_size(static_channels); 

printf("In   badd_call_sch.  init ,    elements    in   static   channels    "); 

printf( "list   =   %d.\n",  channel_count); 

channel_count  =  op_prg_list_size(calls_scheduled); 

printf("In   badd_call_sch.  init ,    elements    in   sch_channels    "); 

printf("list   =  %d.  \n",  channel_count); 


fclose(input_file); 
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/*  Open  file  for  storing  call  timer  information.  */ 

if  ((output_file  =  fopen(" /us r /work/bent on/out put_cal  l_times",  "w")) 

=  NULL) 
( 
badd_calI_sch_error("  Problem  opening  output_call_times    file.", 
OPC_NIL,  OPC_NIL); 


/*  Write  a  file  formal  statement  as  the  first  line  in  the  file.   *l 

fputs("File   Format:    Channel    Enqueued_Time   Dequeued_Time   Time_In_Queue    PCR\n", 
output_file); 

/*  Open  file  for  storing  calls  completed  information.  *l 

if ((output_calls  =  fopen("/usr /work/bent on/out put_call_comple ted",  "w")) 

=  NULL) 
{ 
badd_call_sch_error( "Problem  opening  output_call_completed    file.", 
OPC_NIL,  OPC.NIL); 
} 

/*  Write  a  file  format  statement  as  the  first  line  in  the  file.  */ 

fputs("File  Format:    Channel   Time_completed   PCR  .  \n",  output_calls); 

sch_channel_count  =  op_prg_list_size(static_channels); 

/*  Generate  PID  display  siring.  *l 

sprintf  (pid_string,  "badd_call_scheduler   PID    (%d)  ",  op_pro_id  (op_pro_self  ())); 

/*  Obtain  and  send  out  neighbor  information.  */ 

nbr_data_ptr  =  ams_neighbor_data_build  Q; 

ams_neighbor_notify  (nbr_daia_ptr,  AMSC_MTYPE_AAL_CLIENT); 

if  (LTRACE_CALL_SCHEDULER_ACTIVE) 
{ 

printf("In   badd_call_scheduler .  init :    print   neighbor  info.\n"); 

ams_neighbor_data_print  (nbr_data_ptr,  ams_neighbor_desc_print_noop); 


/*  This  Scheduler  JAodule  is  attached  to  any  process  spawned  by  *l 

I*   this  badd  call  requestor  process.  *l 

I* 'Scheduler  Module  =  (Badd_Sch_Mod_Data*)  op_prg_mem_alloc(sizeof(Badd_Sch_Mod_Data));  */ 

op_pro_modmem_install(&Scheduler_Module); 

/*  Initialize  the  model  parameter  attributes.   *l 

op_ima_obj_attr_get  (my_id,  "scheduler  delay",  &time_to_next_scheduler); 
op_ima_obj_attr_get  (my_id,  "transmission  delay",  &trans_delay); 
op_ima_obj_attr_jget  (my_id,  "channel   delay",  &channel_delay); 
op_ima_obj_attrjget  (my_id,  "calls  pending",  &max_calls_pending); 

/*  Initialize  the  end_sim_time  varaible  */ 
op_ima_sim_attrjget(OPC_IMA_DOUBLE,  "duration",  &end_sim_time); 

if  (LTRACE_CALL_SCHEDULER_ACTIVE) 

{ 

pnntf("Ir.  badd_call_scheduler .  init  state:  Leaving  init  state.  \n"); 
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transition     INIT 

->  confiq 

attribute 

value 

tvoe 

default  value 

name 

tr  1 

string 

tr 

condition 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

line 

toggle 

spline 

unforced  state    confiq 

attribute 

value 

type 

default  value 

name 

enter  execs 
exit  execs 
status 

config 
(empty) 
(See  below.) 
unforced 

string 
textlist 
textlist 
toggle 

St 

(empty) 
unforced 

exit  execs    confiq 


10 


15 


/*  Ams  jrafjgen  expects  either  a  neighbor  notification  interrupt,  */ 

/*  or  a  spurious  signal.  *l 

if  (NEIGHBOR_NOTIFY) 

{ 

/*  This  is  a  'neighbor  notify'  signal.  */ 

if(LTRACE_ACTIVE) 

( 

op_prg_odb_print_major  (pid_string,  "Received  neighbor  notification. ",  OPC_NIL); 


/*  Handle  the  neighbor  notification.  */ 

ams_neighbor_interrupt_handle  (nbr_data_ptr,  badd_call_sch_nbr_intrpt_proc,  OPC_NIL); 


else 


/*  This  is  a  spurious  interrupt.  Handle  appropriately. 
badd_call_sch_spurious_signal_handle  (); 


*/ 
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/*  Compare  the  number  of  calls  in  the  calls ^pending  list.  */ 
/*  If  the  number  exceeds  the  max  calls _pending,  schedule    *l 
I*  a  call  to  execute  the  scheduler.  */ 

number_calls_pending  =  op_prg_list_size(calls_pending); 

if  (LTRACE_CALL_GREEDY_ACTrVE) 

printf( " I n  badd_call_scheduler  .dispatch:    calls   pending   =    %d.  \n",  number_calls_pending); 

if  (number_calls_pending  >  max_calls_pending) 

op  Jntrptscheduleself  (opsimtime  ().  B  ADD_CALL_SCHEDULER); 

/*  Schedule  the  next  scheduling  event  */ 
if  (number_calls_pending  >  0) 

opintrptscheduleself  (opsimtime  ()  +  time_to_next_scheduler,  BADD_CALL_SCHEDULER); 


exit  execs    dispatch 
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temp_intrpt_type  =  op_intrpt_type(); 
temp_intrpt_code  =  op_intrpt_code(); 

if  (LTRACE_CALL_DISP_ACTIVE) 

( 
printf("In  badd_call_scheduler .dispatch 
printf("In   badd_call_scheduler .dispatch 
printf("In  badd_call_scheduler .dispatch 

)  /*  End  if  (LTRACE  CALL  DISP  ACTIVE)  *l 


received  SIGNAL.  \n"); 

intrpt_type  =  %d  .  \n",  temp_intrpt_type); 

intrpt_code  =  %d.  \n",  temp_intrpt_code); 


if  (SIGNAL) 
( 

signa]_iciptr  =  op_intrpt_ici(); 

if  (signal_iciptr  =  OPC_NIL) 

badd_caJI_sch_error( -Unable  to  get   signal_iciptr . 

if  (LTRACE_C  ALL_DISP_ACTIVE) 


,  OPC_NIL,  OPC_NIL): 
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op_ici_print(signaJ_iciptr); 

}  /*  Endif(LTRACE_CALL_DlSP_ACnVE)*l 

op_ici_attr_get(signal_iciptr,  "primitive",  &primitive); 
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sch_channel_iciptr  =  op_intrpt_ici(); 

if  ((op_ici_attr_get  (sch_channel_iciptr,  ■  channel    number  ■ ,  &sch_channel_index)  =  OPC_COMPCODE_FAILURE)) 

badd_call_sch_error("In   start_call:    unable  to  get  values    £rom  sch_channel    iciptr", 
OPC.NIL,  OPC_NIL); 

/*  Destroy  the  ici  to  recover  space.  Garbage  collection.  *l 
op_ici_destroy(sch_channeI_iciptr); 

if  (LTRACE.C  ALL_SCH_ACTIVE) 

printf("In  call   scheduler  .start_call :    sch_channel    index  =   %d.  \n",  sch_channel_index); 
sch_channel_listptr  =  (List*)  op_prg_list_access(calls_scheduled,  sch_channel_index); 
calljciptr  =  (Ici*)  op_prg  list_remove(sch_channelJistptr,  OPC_LISTPOS_HEAD); 

if  (calljciptr  =  OPC_NTL) 

badd_call_sch_error( "  I  n   start   call,    unable  to   get   call_iciptr   from   cal  ls_list . ",  OPC_NrL,  OPC_NTL); 


if  ((op_ici_attr_get  (calljciptr, 
(op_ici_attr_jget  (calljciptr,  " 
(op_ici_attr_get  (call_iciptr,  " 
(op_ici_attr  jget  (call_iciptr,  " 
(op_ici_attr_get  (call_iciptr,  ■ 
(op_ici_attr_get  (call_iciptr,  ■ 
(op_ici_attrjget  (call_iciptr,  ■ 
(op_ici_attr_get  (call_iciptr,  " 
(op_ici_attrjget  (calljciptr,  ■ 
badd_call_sch_error(  "Unable 


•  interarr i va  1   t  ime " ,  &int_arr_time)  =  OPC_COMPCODE_FATLURE)  I 
packet   size",  &packet_size)  =  OPC_COMPCODE_FAILURE)        II 
call   wait   time",&call_wait_time)==OPC_COMPCODE_FAILURE)  II 
call   duration",  &caU_duration)  =  OPC_COMPCODE_FAILURE)     II 
dest   addr",&dest_addr)  =  OPC_COMPCODE_FATLURE)  II 

Qos  class-,&qos_class)  =  OPC_COMPCODE_FAILURE)  II 

AAL  type-,&AAL_type)  =  OPC_COMPCODE_FAILURE)  II 

peak  cell   rate',  &peak_cell_rate)  =  OPC_COMPCODE_FAILURE)  II 
t  ime  queued " ,  &time_enqueued)  =  OPC_COMPCODE_FATLURE)) 
to   get   values    from  call_req    iciptr",  OPC_NIL.  OPC_NIL); 


if  (LTRACE_C  ALL_SCHEDULER_ACTI  VE) 

( 
printf("In  badd_call_scheduler .start_call 
printf("In  badd_call_scheduler .start_call 
printf("In  badd_call_scheduler .start _ca  11 
printf("  In  badd_call_scheduler  .start_call 
printf("In  badd_call_scheduler  .start_call 
printf("In  badd_call_scheduler  .start_call 
pnntf("In  badd_call_scheduler .start_call 
printf( "In  badd_ca  1  l_scheduler . s tart_ca  1 1 

}  /*  End  if (LTRACECALL  SCHEDULER ACTIVE)  */ 


int_arr_time   =   %f  .  \n",  int_arr_time); 
packet_size   =   %d.  \n",  packet_size); 
call_wait_time   =   %f .  \n",  call_wait_time); 
call_duration   =   %l .  \n",  call_duration); 
dest_addr   =   %d .  \n",  dest_addr); 
qos_class   =   %d  .  \n",  qos_class); 
AAL_type   =   %d.\n",  AAL_type); 
peak_cell_rate   =   %  f .  \ n " ,  peak_cell_rate); 


if  (opiciattrset  (calljciptr,  "channel   assigned",  sch_channel_index)  =  OPC_COMPCODE_FAILURE) 
badd_call_sch_error(  "Unable   to   set   sch_channel_index   in   ca  1  l_i c i pt r ",  OPC_NIL,  OPC_NIL); 

time_dequeued  =  op_sim_time(); 
time_in_queue  =  time_dequeued  -  time_enqueued; 

/*  Write  queue  times  to  the  call  timer  output  file.  *l 

fprintf(output_file,  "%d   if   if  %f  %f  \n",  sch_channei_index.  time_enqueued,  time_dequeued, 
time_in_queue,  peak_cell_rate); 
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/*  Update  program  counter  *l 
total_calls_generated  =  total_calls_generated  +  I; 
total_calls_active  =  total_calls_active  +  1; 
if  (total_calls_active  >  max_caUs_active) 
max_calls_active  =  total_calls_active; 

if  (LTRACE_C  ALL_SCHEDULER_ACTIVE) 
{ 
printf("In   badd_call_scheduler,    start;    starting  call    to  dest    %d.\n", 
dest_addr); 
}  /*  if (LTRACE CALL  SCHEDULER _ACTIVE)*I 

I*  Spawn  a  child  process  to  generate  the  call  data  */ 

call_gen_prohandle  =  op_pro_create("clark_badd_call_generator",  OPC_NIL); 

if  (op_pro_valid(call_gen_prohandle)  =  OPQJFALSE) 

{ 
badd_call_sch_error( "Unable   to   create   call   generator  process",  OPC_NIL,  OPC_NIL); 

} 

if  (LTRACE_C  ALL_SCHEDULER_ACTI  VE) 
( 

printf("In  badd_call_scheduler,    start;    invoking   call    generator .  \n"); 

printf("In  badd_call_scheduler. start :    call_iciptr   =   %x .  \n ",  call_iciptr); 

printf("ln  badd_call_scheduler  .start_call ,-   md_aal_module_id  =   %d .  \n " ,  Scheduler_Module.md_aal_module_id): 

)  /*  if  (LJRACE  CALL  SCHEDULER  ACTIVE)  *l 

if  (LTRACE_CALL_TIMER_  ACTIVE) 

printf("ln  badd_call_sch.  start  call:    current   time   =  %f .  \n",  op_sim_time()); 

/*  When  invoking  the  process,  pass  in  the  call  desc  *l 

if  (op_pro_invoke(call_gen_prohandle,  call_iciptr)  =  OPC_COMPCODE_FATLURE) 


badd_call_sch_eiTor( "Unable  to   invoke  call   generator  process",  OPC_NIL,  OPC_NIL); 
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signal_iciptr  =  op_intrpt_ici(); 

if  (signal_iciptr  =  OPC_NIL) 

badd_call_sch_error( "Unable   to   get   signal_iciptr  . ",  OPC_NIL,  OPC_NIL); 

if  (LTRACE_CALL_SCHEDULER_ACTI  VE) 
( 

printf("In  badd_call_scheduler .  send  data:    restarting  call_gen  .  \n"); 

op_ici_print(signal_iciptr); 

}  /*  End  if (LTRACECALL  SCHEDULER  _ACTJVE)  *l 

if  (op_ici_attr_get(signal_iciptr,  "upper   layer  handle",  &upper_handle_iciptr)  =  OPC_COMPCODE_FATLURE) 
badd_call_sch_error( "Unable   to   get   upper    layer  handle. ",  OPC_NIL,  OPC_NIL); 

if  (op_ici_attrjget(upper_handle_iciptr,  "cal  l_gen_prohandle",  &calI_gen_proptr)  =  OPC_COMPCODE_FATLURE) 
badd_call_sch_erTor( "Unable   to   get    call_gen  prohandle. ",  OPC_NIL,  OPC_NIL); 

if  (LTRACE_CALL_TIMER_ACnVE) 

printf("In  badd_call_sch.send  data:    current    time   =    %f .  \n",  op_sim_time()); 

if  (op_pro_invoke(*caU_gen_proptr,  signal_iciptr)  =  OPC_COMPCODE_FAILURE) 
( 
badd_call_sch_error( "Unable   to   restart   call_gen  process  ",  OPC_NBL,  OPC_NIL); 
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if  (signaljciptr  =  OPC_NIL) 

badd_call_sch_error( "Unable   to  get    signal_icipt 


,  OPC_NIL,  OPC.NIL); 
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if  (LTRACE_CALL_SCHEDULER_ACTIVE) 
{ 

printf("In   badd_ca  1  l_scheduler  .call_complete :    restarting   call_gen.  \n"); 

op_ici_print(signal_iciptr); 

}  /*  End  if  (LTRACE  CALL  SCHEDULER  ACTIVE)*  I 

total_calls_received  =  total_calls_received  +  1; 
totaJ_calls_active  =  total_calls_active  -  1; 

if  (op_ici_attr_Jget(signal_iciptr,  "upper   layer  handle",  &upper_handle_iciplr)  =  OPC_COMPCODE_FAILURE) 
badd_caIl_sch_error(  "Unable   to   get    upper   layer  handle. ",  OPC_NIL,  OPC_NIL); 

if  (op_ici_attr_get(signal_iciptr,  "traffic  contract ",  &tmp_traf_con_ptr)  =  OPC_COMPCODE_FAILURE) 
badd_cal]_sch_error(  "Unable  to  get   traffic  contract .",  OPC_NIL,  OPC_NIL); 

if  (op_ici_attr_get(signal_iciptr,  "badd_cal  l_gen_channel_id",  &call_compl_channel)  =  OPC_COMPCODE_FAILURE) 
badd_caIl_sch_error( "Unable  to  get   call_gen  prohandle. ",  OPC_NIL,  OPC_NIL); 

/*   Write  completion  lime  and  PCR  to  the  calls  completed  output  file.  *l 

lemp_PCR  =  tmp_traf_con_ptr->calling_ctd.src_traf_desc.pcr; 

fprintf(output_calls,  "%d  %f  %f  \n",  call_compl_channel,  op_sim_time(),  temp_PCR); 

channel_ptr  =  (Badd_Channel_Desc*)  op_prg_list_access(static_channels,  call_compl_channel); 
channel_ptr->ch_calls_sch  =  channel_ptr->ch_calls_sch  -  1; 
channel_ptr->ch_calls_compl  =  channel_ptr->ch_calls_compl  +  1; 

>f  (op_ici_attr_Jget(upper_handle_iciplr,  "cal  l_gen_prohandle",  &call_gen_proptr)  =  OPC_COMPCODE_FAJLURE) 
badd_calI_sch_error(  "Unable   to  get    call_gen  prohandle. ",  OPC_NIL,  OPC_NEL); 

if  (LTRACE_CALL_TIMER_  ACTIVE) 

printf("In   badd_call_sch.  call    complete:    current    time   =   %f  .  \n".  op_sim_time()); 

if  (op_pro_invoke(*caU_geD_proptr,  signal_iciptr)  =  OPC_COMPCODE_FAILURE) 

{ 
badd_call_sch_eiTor( " Unable   to   restart    call_gen   process",  OPC_NEL.  OPC_NIL); 
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if  (signaljciptr  =  OPC_NIL) 

badd_calI_sch_error(  "Unable   to   get    signal_iciptr . ",  OPC_NIL,  OPC_NIL); 

if  (LTRACE_CALL_SCHEDULER_ACTIVE) 
{ 

printf("In   badd_call_scheduler  .cal  l_released:    restarting   call_gen.  \n  "); 

op_ici_print(signaI_iciptr); 

}  /*  Endif(LTRACE_CALLJCHEDULER_ACTrVE)*l 

if  (op_ici_attr_get(signal_iciptr,  "upper   layer  handle",  &upper_handle_iciptr)  =  OPC_COMPCODE_FAJLURE) 
badd_caJl_sch_error(  "Unable   to   get   upper   layer  handle.  \  OPC_NIL,  OPC_NIL); 

if(op_ici_attrjget(signal_iciptr,  "badd_call_gen_channel_id",  &call_release_channel)  =  OPC_COMPCODE_FATLURE) 
badd_call_sch_error( -Unable   to   get   call_gen  call_release_channel . ",  OPC_NIL,  OPC_NEL); 

channel_ptr  =  (Badd_Channel_Desc*)  op_prg_list_access(static_channels,  call_release_channel); 
channel_ptr->ch_calls_sch  =  channel_ptr->ch_caUs_sch  -  1; 

if  (op_ici_attrjget(upper_handle_iciptr,  -Cal  l_gen_prohandle",  &calI_gen_proptr)  =  OPC_COMPCODE_FAILURE) 
badd_caIl_sch_error( "Unable   to   get   call_gen  prohandle. ",  OPC_NIL,  OPC_NIL); 

total_calls_active  =  tota]_calls_active  -  1; 

if  (op_pro_invoke(*caU_gen_proptr,  signaljciptr)  =  OPC_COMPCODE_FAILURE) 
{ 
badd_call_sch_error( "Unable  to  restart   call_gen  process",  OPC_NIL,  OPC_NIL); 
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/*  This  Scheduler  Module  is  attached  to  any  process  spawned  by  *l 
I*  this  badd_call_scheduler  process.  *l 

op_pro_modmem_install(&Scheduler_ModuIe); 

/*  Pass  the  neighbor  information  to  all  children  processes.      */ 
Scheduler_Module.md_neighbor_dala_ptr  =  nbr_data_ptr, 
Scheduler_Module.md_aaI_module_id  =  aal_module_id; 
Scheduler_Module.md_to_aal_stream_index  =  to_aal_stream_index; 
Scheduler_Module.md_calls_pending_ptr  =  calls_pending; 
Scheduler_Module.md_channel_delay  =  channel_delay; 


transition    shared  data 

->  dispatch 

attribute 

value 

tvpe 

default  value 

name 

tr  121 

string 

tr 

condition 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

spline 

toggle 

spline 

unforced  state    error 

attribute 

value 

tvoe 

default  value 

name 

enter  execs 
exit  execs 
status 

error 

(See  below.) 

(empty) 

unforced 

string 
textlist 
textlist 
toggle 

St 

(empty) 
unforced 

enter  execs    error 

5 

/*  This  is  a  spurious  interrupt.  Handle  appropriately. 

printf("Bad   signal    received  by  badd_call_scheduler 
badd_call_sch_spurious_signal_handle  (); 

\n»); 

*/ 
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/*  Print  Information  during  testing  */ 

printf( "Calls   currently  active   is   %d .  \n",  total_calls_active); 

printf("Max   calls   active    in   this    run  was   %d.  \n",  max_calls_active); 

calls_list_size  =  op_prg_list_size(calls_pending); 

printf( "Calls   remaining   in  the  calls_pending   list   at   termination   =   %d .  \n",  calls_list_size); 

printf(  "Calls   remaining   in  the  calls_scheduled   lists   at   termination.  \n"); 

time_dequeued  =  end_sim_time; 

for  (channel_index  =  0;  channel_index  <  sch_channel_count;  channel_index++) 
{ 

channel_ptr  =  (Badd_Channel_Desc*)  op_prg_list_access(static_channels,  channel_index); 

calls_list_size  =  channel_ptr->ch_calls_sch; 

call_compl_channel  =  channel_ptr->ch_calls_compl; 

channel_compI_time  =  channel_ptr->ch_compl_time; 

printf("  Channel    %d:    calls   compl    =   %d,    calls   remaining   =   %d,    completion   time   =   %f.\n" 

channel_index,  calI_compl_channel,  calls_list_size,  channel_compl_time); 

channel_listptr  =  (List*)  op_prg_list_access(calls_scheduled,  channel_index); 

for  (sch_channel_index  =  0;  sch_channel_index  <  calls_list_size;  sch_channel_index-t-+) 
{ 
call_iciptr  =  (Ici*)  op_prg_list_access(channel_listptr,  sch_channel_index); 

if((op_ici_attr_get(call_iciptr,  "time  queued",  &time_enqueued)  =  OPC_COMPCODE_FATLURE)) 
badd_call_sch_error("In   End   Sim:    unable  to  get   values    from  call_req   iciptr", 
OPC.NIL,  OPC.NIL); 

time_in_queue  =  time_dequeued  -  time_enqueued; 

/*  Write  queue  times  to  the  call  timer  output  file.  *l 

fprintf(output_file,  "%d   %f   %f  %f  \n\  channel_index,  time_enqueued,  0.0,  0.0); 
/*        fprintfioutpuljile,  "%d  %f%f%f\n",  channel _index,  time  ^enqueued,  time  jdequeued, 
I*  lime_in_queue);  *l 

) 

if  (LTRACE_CALL_SCH_ACTrVE) 

( 
badd_call_sch_list_print(channel_listptr); 

) 

) 

/*  Close  the  Output  files.  *l 

fclose(ourput_file); 

fclose(ourput_cal!s); 

badd_call_sch_error(" Ending   simulation    in   badd_call_scheduler.End   Sim.  \n",  OPC_NIL,  OPC_NIL); 


exit  execs    End  Sim 
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/*  A  call  jrequest  arrived  from  the  call  requestor  above.  *l 
I*  Must  capture  the  call  jrequest  information  from  the  *l 
I*  ICI  and  store  the  call  in  the  call_pending_lisi         */ 

reqjciptr  =  op_intrpt_ici(); 

if  (reqjciptr  =  OPC_NIL) 

badd_call_sch_error( "Unable   to  get   call_req   iciptr .  ",  OPCJMIL,  OPC_NIL); 

if  ((op  ici_attr_get  (reqjciptr,  ■  interarrival   t ime " ,  &int_arr_time)  ==  OPC_COMPCODEJFATLlJRE)  II 
(op  ici_attr_get  (reqjciptr,  -packet   size",  &packet_size)  =  OPC.COMPCODEJ^ATLURE)         II 
(op Jci_attr_get  (reqjciptr,  "call  wait   time",  &call_wait_time)  =  OPC_COMPCODEJFATLURE)  II 
(op_ici_attr_get  (reqjciptr,  "call  duration",  &call_duration)  =  OPCjrOMPCODEJ^ATLURE)    II 
(opJci_attr_get  (reqjciptr,  "dest  addr ",  &dest_addr)  =  OPCJTOMPCODEJ^ATLURE)  II 

(op  iciattrjget  (req_iciptr,  "QoS  class",  &qos_class)  =  OPC.COMPCODEJ^ATLURE)  II 

(op  ici_attr_get  (reqjciptr,  ■  AAL  ty pe " ,  &AAL_type)  =  OPC.COMPCODE J^ATLURE)  II 

(op  ici_attr_get  (reqjciptr,  "peak  cell   rate",  &peak_cell_rate)  =  OPC_COMPCODEJ^AILURE)) 
badd_calI_sch_error("ln  badd_call_sch.call_req:    unable  to  get  values   from  call_req  iciptr" 

/*  Destroy  the  ici  to  recover  space,  garbage  collection.  *l 
op_ici_destroy(reqJciptr); 


OPC  NIL,  O 


if  (LTRACE_C  ALL_SCHEDULER_ACTIVE) 


printf( 
printf( 
printf( 
printf( 
printf( 
printf( 
printf( 
printf( 
printf( 
}/*  End 


'In  badd_call_s 
'In  badd_call_s 
'In  badd_call_s 
'In  badd_call_s 
'In  badd_call_s 
'In  badd_call_s 
'In  badd_call_s 
'In  badd_call 
'In  badd_call_s 
if(LTRACE_CALL 


cheduler.cal 
cheduler .cal 
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cheduler.cal 
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SCHEDULER 


l_request : 
l_request : 
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ACTIVE)  *l 


int_arr_time   =   %t .  \n",  int_arr_time); 
packet_size   =   %d  .  \n",  packet_size); 
call"_wait_time  =    %f  .  \n",  call_wait_time); 
call_duration  =   %f  .  \n",  call_duration); 
dest_addr   =   *d.  \n",  dest_addr); 
qos_class   =   %d.  \n",  qos_class); 
AAL_t  ype   =   %  d .  \  n " ,  AAL_type); 
peak_cell_rate   =   % f  .  \n " ,  peak_cell_rate); 
req_iciptr   =   %x .  \n",  reqjciptr); 


/*  Create  and  set  the  fields  in  the  interface  ICI.  *l 

I*  -  Using  local  memory  —  *l 

ifjciptr  =  opJci_create  ("badd_call_req_i£_ici "); 

op_ici_attr_set  (ifjciptr,  "interarrival   time",  int_arr_time); 
op_ici_attr_set  (ifjciptr,  "packet   s ize ",  packet_size); 
op_ici_attr_set  (ifjciptr,  "call   wait  time",  call_wait_time); 
op_ici_attr_set  (if Jciptr,  "call   duration",  call_duration); 
op_ici_attr_set  (ifjciptr,  "dest  addr",  dest_addr); 
op_ici_attr_set  (ifjciptr,  "QoS  class",  qos_class); 
op_ici_attr_set  (if  Jciptr,  "AAL  type",  AAL_type); 
op jci_attr_set  (if  Jciptr,  "peak  cell   rate",  peak_cell_rate); 
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op_prg_list_insert(calls_pending.  if.iciptr,  OPC_LISTPOS_TAIL); 

total_calIs_requested  =  total_ca!ls_requested  +  1; 

/*  Send  an  intrpt  to  start  the  scheduler  if  not  requested.  */ 
sch_requested  =  OPC_COMPCODE_FAILURE; 

this_event  =  op_ev_current(); 

next_event  =  op_ev_next_local(this_event); 

while  (op_ev_valid(next_event)) 

{ 
if  ((op_ev_type(next_event)  =  OPC_INTRPT_SELF)  && 

(op_ev_code(next_event)  =  BADD_CALL_SCHEDULER)) 
{ 

if  (LTRACE_CALL_SCH_  ACTIVE) 

printf( "Found   scheduler  event,    stopping   search.  \n"); 

sch_requested  =  OPC_COMPCODE_SUCCESS; 

break; 
} 
else 


next_event  =  op_ev_next_local(next_event); 


} 


l*if(sch_requested  ==  OPC COMPCODE FAILURE) 

l*{ 

I*    if  (LTRACE_CALL_SCH  ACTIVE) 

I*        printfC 'Sending  for  scheduler  interrupt. \n"); 

I*     op_intrpt_schedule_self(opjim_iime  (),  BADDCALLJCHEDULER); 

I*)  *l 
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/*  Disable  the  intrpts  to  make  this  process  atomic.  *l 
op_intrpt_disable(OPC_INTRPT_SELF,  BADD_CALL_SCHEDULER,  OPC.FALSE); 
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/*  Remove  all  the  other  events  of this  type  from  the  events  list.  *l 

this_event  =  op_ev_current(); 

next_event  =  op_ev_next_local(this_event); 

while  (op_ev_valid(next_event)) 

{ 
if  ((op_ev  type(next_event)  =  OPC_INTRPT_SELF)  && 
(op_ev_code(next_event)  =  BADD_CALL_SCHEDULER)) 

( 
if  (LTRACE.C  ALL_SCH_ACTIVE) 

printf(  •  Found  next    sch   event,    deleting  event.  \n"); 
scheduler_event  =  next_event; 
next_event  =  op_ev_next_local(scheduler_event); 
op_ev_cancel(scheduler_event); 


else 


next_event  =  op_ev_next_local(next_event); 


/*  Determine  the  number  of  calls  that  must  be  scheduled,  */ 
calls_list_size  =  op_prg_list_size(calls_pending); 

if  (LTRACE_CALL_GREEDY_ACTrVE) 

( 

if  (calls_list_size  =  0) 

printf(*In   badd_cal  l_scheduler  .call    scheduler,    attempted   to   schedule   empty    list."); 
else 

printf("In  badd_call_scheduler .call    scheduler,    calls   list    size   =   %d.  \n",  calls_list_size); 
} 

/*  Initialize  variables  for  find  first  call  and  channel  to  schedule.  */ 
least_compl_time  =  MAX_COMPL_TIME; 
least_channel  Judex  =  - 1 ; 
least_call_index  =  -1; 

/*  Create  and  Initialize  the  scheduling  matrix.  */ 

temp_calls_schjist  =  op_prg_list_create(); 

for  (row_index  =  0;  row  Jndex  <  calls_list_size;  row_index++) 

{ 

/*  Access  a  call  description  in  the  calls _pending  list.  */ 

call_iciptr  =  (Ici*)  op_prg_list_access(calls_pending,  row_index); 

if  (call_iciptr  =  OPC_NIL) 

badd_call_sch_error( " I n   badd_call_scheduler.call   schedule,    unable   to  get   call_iciptr . ", 
OPC_NIL,  OPC_NIL); 

/*  Gel  the  call-duration,  call  wait _time,  and  peak  cell  jraie  from  the  call  descriptor .  *l 
if  ((op_ici_attr_get  (calljciptr,  "call   duration",  &call_duration)  =  OPC_COMPCODE_FATLURE)  II 
(op_ici_attr_get  (calljciptr,  "call  wait   time',  &call_wait_time)  ==  OPC_COMPCODE_FAILlJRE)  II 
(op  iciattr^get  (calljciptr,  "peak  cell    rate".  &peak_cell_rate)  =  OPC_COMPCODE_FAILURE)) 
badd_call_sch_error("In   badd_sch.call    schedule:    unable   to  get   values    from  call_req   iciptr. 
OPCJSIL,  OPC_NIL); 

if  (LTRACE_C  ALL.GREED  Y_ACTIVE) 


{ 


printf("In   badd_call_scheduler .call    schedule:    peak_cel l_rate   =   %f.\n", 

peak_cell_rate); 
/*  End  if(LTRACE_CALL_SCHEDULER_ACTIVE)  */ 
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call_bit_rate  =  peak_cell_rate  *  AMSC_ATM_CELL_SIZE; 

/*  Create  channels  list  for  this  call.  *l 
sch_channel_listptr  =  op_prg_list_create(); 
if  (sch_channel_listptr  =  OPC_NEL) 

badd_call_sch_error( " In  badd_call_scheduler .call    schedule,    unable   to  create   sch_channel_listptr . 
OPC_NIL,  OPC_NIL); 

/*  Insert  the  channels  list  into  the  scheduling  matrix  as  a  row.  */ 
op_prg_list_insert(temp_calls_sch_list,  sch_channel_listptr,  OPC_LISTPOS_TAIL); 

/*  Calculate  the  completion  lime  for  this  call  on  every  channel  and  store  in  the  scheduling  */ 
/*  matrix.  */ 

for  (col_index  =  0;  col_index  <  sch_channel_count;  col_index++) 
( 

/*  Allocate  space  to  store  channel  completion  lime.  */ 

compl_time_ptr  =  (double*)  op_prg_mem_alloc(sizeof( double)); 

if  (LTRACE.C  ALL_GREEDY_ACTIVE) 


{ 


printf("ln   badd_call_scheduler .call    scheduler:    row_index   =   %d,    col_index   =   %d.\n", 
row_index,  col_index); 


/*  Get  the  channel  descriptor.  */ 

channel_ptr  =  (Badd_Channel_Desc*)  op_prg  list_access(static_channels,  col_index); 

if  (LTRACE.C ALL_GREEDY_ACTIVE) 

{ 
printf("In  badd_call_scheduler  .call    scheduler,    ch_capacity   =   %d.  \n",  channel_ptr->ch_capacity); 
printf("In  badd_call_scheduler .call    scheduler,    bit    rate   =   %d.  \n",  call_bit_rate); 


/*  Determine  if  this  channel  can  support  the  call  */ 
if  (call  bit_rate  <=  channel_ptr->ch_capacity) 

{ 
if  (op_sim_time  ()  >  channe)_ptr->ch_compl_time) 

{ 
*compl_time_ptr  =  op_sim_time()  +  call_duration  +  channel_delay  +  trans_delay; 
/*  *compl_lime_ptr  =  op_sim_time()  +  call_duralion;  *l 

) 

else 
{ 
*compl_time_ptr  =  channel_ptr->ch_compl_tune  +  call_duration  +  channel_delay  +  trans_delay; 
/*  *compl_time_ptr  =  channel _ptr->ch _com.pl jime  +  call  duration;  *l 


I*  Determine  if  this  channel  has  a  shorter  completion  lime  than  all  previous  channels.  *l 
if  (*compl_time_ptr  <  least_compl_time) 
{ 

least_channel_index  =  col_index; 

least_call_index  =  row_index; 

least_compl_time  =  *compl_time_ptr; 


else 

( 


*compl_time_ptr  =  MAX_COMPL_TIME; 
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if  (LTRACE_CALL_GREEDY_ACTrVE) 

( 
printf("In   badd_cal  l_scheduler  .cal  1    schedule:    compl    time   =   %f.\n", 
*compl_time_ptr); 
)  /*  End  if  {LTRACE  CALL  GREEDY  ACTIVE)  */ 

/*  Store  the  completion  time  in  the  matrix.  */ 
op_prg_list_insert(sch_channel_listptr,  compl_time_ptr,  OPC_LISTPOS_TAIL); 

}   /*  End  for  (col  index  =  0;  coljndex  <  sch  channel  count;  col  Jndex++)  *l 
}   I*  for  (row jndex  =  0;  row  jndex  <  calls _lisl_size;  row_index+  +  )  */ 

/*  Initialize  the  number  of  calls  to  schedule.  *l 
remain_to_schedule  =  calls_list_size; 

while  (remain_to_schedule  >  0) 

{ 
/*  During  initialization  of  scheduling  matrix,  found  the  first  call  and  channel  to  schedule.  */ 
/*  On  all  subsequents  calls,  call  and  channel  to  schedule  are  completed  at  the  end  of  the      */ 
/*  while  loop.  *l 

if  (LTRACE_C  ALL_GREEDY_ACTIVE) 
( 

printf("In  badd_cal l_scheduler .call    schedule:    least_channel   %d,    least_call    %d,    least_compl    %f.\n' 
least_channel_index,  least_call_index,  least_compl_tinie); 

badd_call_sch_matrix_print(temp_calls_sch_Iist); 
} 

if  (least_call_index  <  0) 

badd_call_sch_error( "Unable   to   schedule  any  calls,    call    exceeds   channel   capacities.", 
OPC_NIL,  OPC_NIL); 

/*  Remove  the  call  from  the  calls  pending  list.  *l 

call_iciptr  =  (Ici*)  op_prg_list_remove(calls_pending,  least_call_index); 

/*  Time-stamp  the  request  with  the  current  time.  */ 
op_ici_attr_set  (call_iciptr,  "time  queued",  op_sim_time()); 

/*  Put  the  call  at  the  tail  of  the  correct  channel  calls jscheduled  list.  *l 
channel_listptr  =  (List*)  op_prg_list_access(calls_scheduled,  least_channel_index); 
op_prg_listJnsert(channelJistptr,  call_iciptr,  OPC_LISTPOS_TAIL); 

/*  Remove  the  row  from  the  matrix  and  return  the  memory  to  system.  This  kernal  */ 
/*  process  also  deallocates  all  memory  for  the  list  elements.  */ 

row_listptr  =  (List*)  op_prg_list_remove(temp_calls_sch_list,  least_call_index); 
op_prg_list_free(row_listptr); 

/*  Update  the  calls  scheduled  counter  */ 

channel_ptr  =  (Badd_Channel_Desc*)  op_prg_list_access(static_channels,  least_channel_index); 

channel_ptr->ch_calls_sch  =  channel_ptr->ch_calls_sch  +  1; 

/*  If  this  is  the  first  call  on  the  channel,  start  the  channel.  *l 
if  (channel_ptr->ch_calls_sch  =  0) 

{ 
if  (LTRACE_C  ALL_GREEDY_ACTIVE) 


{ 


printf("In   badd_call_scheduler .call    scheduler,    calling   start   call    for  channel   %d.\n" 
least_channel_index); 
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/*  Identify  the  channel  to  start  sending  data.  *l 
channel_iciptr  =  op_ici_create(  "badd_channel_ici  "); 
op_ici_install(channel_iciptr); 

op_ici_attr_set  (channeMciptr,  "channel   number",  least_channel_index); 
opintrptscheduleself  (opsimtime  (),  BADD_CALL_SCH_START); 
} 

/*  Update  the  channel  completion  timer.  *l 

if  ((op_ici_attr_get  (calljciptr,  "call   dura t  ion",  &call_duration)  =  OPC_COMPCODE_FAILURE)  II 
(op_ici_attr_get  (calljciptr,  "call  wait  t  i me " ,  &call_wait_time)  =  OPC_COMPCODE_FAILURE)) 
badd_call_sch_error("In  badd_sch.call    schedule:    unable   to  get   values   from  call_iciptr . ", 
OPC.NEL,  OPC_NIL); 

if  (op_sim_time  ()  >  channeI_ptr->ch_compl_tinie) 
{ 
channel_ptr->ch_compl_time  =  op_sim_time()  +  call_duration  +  channel_delay  +  trans_delay; 
/*         channel _ptr->ch_compl_time  =  op_sim_time()  +  calljduration;  */ 

) 
else 

{ 
channel_ptr->ch_compl_time  =  channel_ptr->ch_compl_time  +  call_duration  +\ 
+  channel_delay  +  trans_delay; 
/*         channel _ptr->ch_compl _lime  =  channel _plr->ch_compl_lime  +  call  duration;  */ 
} 

if  (LTRACE_C  ALL_GREEDY_ACTrVE) 

{  ' 

printf("In  badd_call_scheduler  .call_schedule:    compl_time   =   %f  .  \n",  channel_ptr->ch_compl_tinie); 

printf("In  badd_call_scheduler  .call    scheduler:    call   scheduled.  \n"); 
} 
channel_scheduled  =  OPC_COMPCODE_SUCCESS; 

remain_to_schedule  =  remain_to_scheduIe  -  1; 

col_index  =  least_channel_index; 

least_channel_index  =  -1; 

least_call_index  =  -I; 

least_compl_time  =  MAX_COMPL_TIME; 

/*  Get  the  channel  completion  lime  and  update  the  channel  column  in  the  scheduling  matrix.  */ 
channel_ptr  =  (Badd_Channel_Desc*)  op_prg_list_access(static_channels,  col_index); 

/*  Step  through  each  job  in  the  calls _pending  list  and  update  the  channel  column  in  the  */ 
/*  scheduling  matrix  with  a  new  channel  completion  lime.  */ 

for  (row_index  =  0;  row_index  <  remain_to_schedule;  row_index++) 
{ 

if  (LTRACE.C  ALL_GREEDY_ACTrVE) 


{ 


printf("In  call_scheduler .cali_schedule:    updating   row  %d,    col    %d.\n", 
row_index,  col_index); 


/*  Get  the  location  for  the  current  matrix  element.  *f 

sch_channel_listptr  =  (List*)  op_prg_list_access  (temp_calls_sch_list,  row_index); 

compl_time_ptr  =  (double*)  op_prg_list_access  (sch_channel_listptr,  col_index); 

/*  Only  update  the  completion  lime  if  the  call  can  run  on  this  channel.  */ 
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if  (*compl_time_ptr  <  MAX_COMPL_TIME) 
( 
/*  Gel  the  call _duralion  time  from  the  call  descriptor.  */ 
calljciptr  =  (Ici*)  op_prg_list_access(calls_pending,  row_index); 

if  ((op_ici_attr_get(call_iciptr,  "call   duration",  &call_duration)  =  OPC_COMPCODE_FATLURE)) 
badd_call_sch_error(" In   cal  l_scheduler  .schedule:    unable   to   get   cal  l_durat  ion.  ", 
OPC.NTL,  OPC_NEL); 

if  (op_sim_time  ()  >  channel_ptr->ch_oompl_time) 
( 
*compl_time_ptr  =  op_sim_time()  +  call_duration  +  channel_delay  +  trans_delay; 
*compltime_ptr  =  op_sim_lime()  +  call_duration;  */ 

} 

else 
{ 
*compl_time_ptr  =  channel_pti->ch_compl_time  +  caIl_duration  +  channel_delay  + 
trans_delay; 
*compljimejptr  =  channel  j>lr->ch  _compl  jime  +  call  _duralion;  *l 
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}  /*  Endif(*compl_time_pir<MAX_COMPLTME)*l 

}  I*  End  for  (row_index  =  0;  row  index  <  remain  jo  _schedule ;  row_index++)  */ 

I*  After  updating  the  completion  time  for  each  call,  step  through  the  entire  scheduling  */ 
/*  matrix  looking  for  the  next  call  to  schedule.  */ 

for  (row_index  =  0;  row_index  <  remain_to_schedule;  row_index++) 

{ 
for  (col_index  =  0;  col_index  <  sch_channel_count;  col_index++) 
{ 

/*  Get  the  current  location  in  the  scheduling  matrix.  *l 

sch_channel_listptr  =  (List*)  op_prg_list_access  (temp_calls_sch_list,  row_index); 

compl_time_ptr  =  (double*)  op_prg_list_access  (sch_channel_listptr,  col_index); 

/*  Determine  if  this  channel  has  the  shortest  completion  time.  *l 

if  (*compl_time_ptr<  least_compl_time) 

{ 

least_channel_index  =  col_tndex; 

least_call_index  =  row_index; 

least_compl_time  =  *compl_time_ptr; 
)  /*  End  if  (*compl  jime _ptr  <  least _compl  jime)  */ 

}   /*  End  for  (colindex  =  0;  colindex  <  sch  channel  count;  col_index++)  *l 

}  I*  End  for  (rowjndex  =  0;  row  index  <  remain  _to_schedule;  row_index+  +)  */ 

)  /*  End  while  {remain  jo  schedule  >  0)  */ 

/*  remove  the  list  to  deallocate  memory  resources;  garbage  collection.  */ 
op_prg_list_free(temp_calls_sch_list); 

/*  Turn  the  interrupts  back  on.  *l 
op_intrpt_enable(OPC_INTRPT_SELF,  BADD_CALL_SCHEDULER); 
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req_iciptr  =  op_intrpt_ici(); 

if  (reqjciptr  =  OPC_NIL) 

badd_call_sch_error( "Unable   to   get   call_req    iciptr . ",  OPC_NIL,  OPC_NIL); 


if  ((op_ici_attr_get  (req_iciptr, 
(op_ici_attrj>et  (reqjciptr, 
(op_ici_attr_get  (reqjciptr, 
(op_ici_attr_get  (reqjciptr, 
(op_ici_attrj>et  (reqjciptr, 
(op_ici_attr_get  (reqjciptr, 
(op_ici_attr_get  (reqjciptr, 
(op_ici_attr_get  (reqjciptr, 
(op_ici_attr_get  (reqjciptr, 


"interarri val   time",  &int_arrjime)  =  OPC_COMPCODE_FATLURE)  II 

" pa  cket   size",  &packet_size)  =  OPC.COMPCODE J^ATLURE)         II 

"call  wait   time",  &call_wait_time)  =  OPC_COMPCODEJ^ATLLTRE)  II 

■call   duration • ,  &call_duration)  =  OPC_COMPCODE J^ATLURE)     II 

"dest   addr".&dest_addr)==OPC_COMPCODEJFAILURE)  II 

■Qos  class ",&qos_cIass)  =  OPC_COMPCODE_FATLURE)  II 

"AAL  type",&AAL_type)  =  OPC_COMPCODE_FArLURE)  II 

"peak  cell   rate",  &peak_cell_rate)  =  OPC_COMPCODEJ=ATLURE)  II 

" channe  1   a ss i gned " ,  &cail_release_channel)  =  OPC_COMPCODE_FATLURE)) 


badd_call_sch_error( "  I  n   badd_call_sch.  reschedule:    unable   to   get    values    from  call_req    i  c  i  pt  r " ,  OPC  JVIL 
op_ici_destroy(  reqjciptr); 


if  (LTRACE_CALL_RESCHEDULER_  ACTIVE) 

{ 

printf( "In  badd_ca  1  l_scheduler . reschedu le 

printf("In  badd_call_scheduler .reschedule 

printf( "In  badd_ca  1  l_scheduler . reschedule 

printf("In  badd_call_scheduler .reschedule 

printf( "  In  badd_call_scheduler .  reschedule 

printf("  In  badd_call_scheduler  .  reschedule 

printf("  In  badd_call_scheduler .  reschedule 

printf(  "In  badd_call_scheduler .  reschedule 

printf("  In  badd_call_scheduler .  reschedule 


int_arr_time   =   %f .  \n",  int_arr_time); 
packet_size   =   %d .  \n",  packet_size); 
call_wait_time   =   %1 .  \n",  call_wait_time); 
call_duration   =   %f  .  \n ",  call_duration); 
dest_addr   =   %d  .  \n",  dest_addr); 
qos_class   =   %d .  \n",  qos_class); 
AAL_type   =   %d.\n",  AALjype); 
peak_cell_rate   =   %f  .  \n",  peak_cell_rate); 
req_iciptr   =   %x.  \n ",  reqjciptr); 


printf("In   badd_call_scheduler. reschedule:    current    sim  time 
/*  End  if(LTRACECALLRESCHEDULERACnVE)  *l 


%f  .  \n",  op_sim_time()); 


/*  Reduce  the  channel  completion  lime  for  this  call,  it  is  added  back  in  when  the  call  */ 

/*  is  rescheduled.  *l 

channel_ptr  =  (Badd_QianneLDesc*)  op_prg_list_access(static_channels,  call_release_channel); 
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45 
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55 


channel_ptr->ch_compl_time  =  channeI_ptr->ch_compl_time  -  call_duration  -  channel_delay  -  trans_delay; 

/*  Create  and  set  the  fields  in  the  interface  ICl.  */ 

if_iciptr  =  op_ici_create  ("badd_call_req_ii_ici "); 

op_ici_attr_set (if_iciptr,  "interarrival   time",  int_arr_time); 
op_ici_attr_set  (if_iciptr,  " packet  size",  packet_size); 
op_ici_attr_set  (if_iciptr,  "call  wait  t  ime",  call_wait_time); 
op_ici_attr_set  (if_iciptr,  "call   durat  i on " ,  calI_duration); 
op_ici_attr_set  (if_iciptr,  "dest   addr",  dest_addr); 
op_ici_attr_set  (if_iciptr,  "QoS  class",  qos_class); 
op_ici_attr_set  (if_iciptr,  "AAL  type " ,  AAL_type); 
op_ici_attr_set  (if_iciptr,  "peak   cell    rate",  peak_cell_rate); 

op_prgJist_insert(calIs_pending,  if_iciptr,  OPC_LISTPOS_HEAD); 

/*  if(schjequested  ==  OPCCOMPCODEFA1LURE) 

I*     opjntrpt  schedule  jelf (op  Jimjime  (),  BADDCALLJSCHEDULER);  *l 
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10 


/*  Get  the  lei  passed  from  the  call  generator  and  determine  what  channel  must       */ 
/*  be  checked  for  additional  calls.  If  the  channel  has  additional  calls  waiting,  *l 
I*  then  send  an  interrupt  to  start  the  next  call.  *l 

check_channel_iciptr  =  op_intrpt_ici(); 

if  (op_ici_attr jget  (check_channel_iciptr,  "channel    number",  &check_chan_index)  =  OPC_COMPCODE_FATLURE) 
badd_call_sch_error( "Unable   to   read   check   channel    icipt  r .  ",  OPC_NIL,  OPC_NIL); 

op_ici_destroy(check_channel_iciptr); 

if  (LTRACE_CALL_SCH_ACTIVE) 

printf("In  badd_call_scheduler.call    scheduler  .check_channel :    channel    =   %d.  \n",  check_chan_index): 
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channel_ptr  =  (Badd_Channel_Desc*)  op_prg_list_access(static_channe!s,  check_chan_index): 

/*  Check  the  channel  for  additional  calls  wailing  and  start  the  next  call  if  available.  */ 

if  (channel_ptr->ch_calls_sch  >=  0) 

{ 

channeMciptr  =  op_ici_create(  "badd_channel_ici "); 

op_ici_instalI(channel_iciptr); 

op_ici_attr_set  (channeMciptr,  "channel   number",  check_chan_index); 

opjntrptscheduleself  (op_sim_time  ()  +  channel_delay,  BADD_CALL_SCH_START); 


if  (LTKACE_CALL_TIMER_  ACTIVE) 

printf("In   badd_call_sch.  check  channel:    current   time   =    %t .  \n",  op_sim_time()); 
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